[OSM-talk-fr] Fwd: [OSM-talk-fr-bzh] Fwd: [liste-egc] CfP: 1st Int. Workshop on Open Data -- May, 25 2012 - Nantes, France
Pour info... Romain -- Message transféré -- De : Cécile Bothorel cecile.botho...@telecom-bretagne.eu Date : 25 janvier 2012 17:27 Objet : [OSM-talk-fr-bzh] Fwd: [liste-egc] CfP: 1st Int. Workshop on Open Data -- May, 25 2012 - Nantes, France À : Roll Breizhad OSM talk-fr-...@openstreetmap.org Bonjour, Les chercheurs organisent un workshop sur la thématiques de open data. Probablement très intéressant en termes de challenges techniques. Cécile Message original Sujet: [liste-egc] CfP: 1st Int. Workshop on Open Data -- May, 25 2012 - Nantes, France Date : Wed, 25 Jan 2012 14:37:06 +0100 De : Marc Gelgon marc.gel...@univ-nantes.frmarc.gel...@univ-nantes.fr Répondre à : Marc Gelgon marc.gel...@univ-nantes.fr marc.gel...@univ-nantes.fr Pour : liste-...@polytech.univ-nantes.fr CALL FOR PAPERS First International Workshop on Open Data (WOD-2012) May 25, 2012 - Nantes, France http://sites.google.com/site/opendata2012/ *** Submission Deadline --- February 29, 2012 *** -- While being most commonly known from the recent Linked Open Data movement, the concept of publishing data explicitly as Open Data has meanwhile developed many variants and facets that go beyond publishing large and highly structured RDF/S repositories. Open Data comprises text and semi-structured data, but also open multi-modal contents, including music, images, and videos. With the increasing amount of data that is published by governments (see, e.g., data.gov, data.gov.uk or data.gouv.fr), by international organizations (data.worldbank.org or data.undp.org) and by scientific communities (tdar.org, cds.u-strasbg.fr, GenBank, IRIS or KNB) explicitly under an Open Data policy, new challenges arise not only due to the scale at which this data becomes available. A number of community-based conferences accommodate tracks or workshops which are dedicated to Open Data. However, WOD aims to be a premier venue to gather researchers and practitioners who are contributing to and interested in the emerging field of managing Open Data. Hence, it is a unique opportunity to find in a single place up-to-date scientific works on Web-scale Open Data issues that have so far only partially been addressed by different research communities such as Databases, Data Mining and Knowledge Management, Distributed Systems, Data Privacy, and Data Visualization. The 1st International Workshop on Open Data (WOD) is one of the very first events that stresses new and exciting challenges offered by the emerging field of Open Data. It aims at facilitating new trends and ideas from a broad range of topics concerned within the widely-spread Open Data movement. TOPICS OF INTEREST -- Provided that Open Data is at the heart of the submission, topics of interest for WOD-2012 include, but are not limited to: - Big Data Management - Data Management in the Cloud - Web Data Integration - Linked Data and the Semantic Web - Data Science and Data Analytics - Social Web - Data Privacy - Data Visualization - Data Curation - Data Provenance Every submission that jointly covers one or several of the above topics is warmly encouraged. The content of submissions is expected to meet the standards of international conferences and workshops. Vision and position papers are specifically welcome. PAPER SUBMISSION AND PUBLICATION - Authors are invited to submit original, unpublished research papers that are not being considered for publication in any other forum. Papers submitted cannot exceed six letter-size (8.5 X 11) pages in length, including all references and appendices. Manuscripts are limited to 6 pages, single spacing, double column, and must strictly adhere to the template format. Guidelines on paper submission and formatting are available at http://sites.google.com/site/opendata2012/. Accepted papers will appear in an ePrint arXiv proceedings volume with Open Access. At least one author of each accepted paper is required to register and present his/her work at the workshop. Extended versions of selected papers will be considered for possible publication as special issue of a general-purpose journal (e.g. ACM Trans. on the Web or IEEE TKDE), or will be compiled into a formal post-proceedings volume (with a unique ISBN assigned to it) from a Springer-like publisher. IMPORTANT DATES -- Submissions due on Feb 29, 2012 (6PM GMT) Notifications out on Apr 6, 2012 Camera-ready due on Apr 22, 2012 Workshop on May 25, 2012 PROGRAM COMMITTEE (confirmed so far) --- Omar Alonso, Microsoft Research Sihem Amer-Yahia, QCRI and CNRS Sören Auer, Univ. Leipzig Jean-Daniel Fekete, Inria David Gross-Amblard, Univ. of Rennes Frank van Ham, IBM Katja Hose,
Re: [OSM-talk-fr] Open Data
L'argumentation me semble bien faible. On a plutôt l'impression que vous défendez votre beefsteak. -- View this message in context: http://gis.19327.n5.nabble.com/Open-Data-tp5380489p5432250.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] Open Data
Le 26/01/2012 01:51, Philippe Verdy a écrit : Le 25 janvier 2012 23:36, Emilie Laffray emilie.laff...@gmail.com a écrit : L'utilisation commercial fait partie du libre. Ajouter une restriction NC enlève le côté libre. D'accord, mais à condition de l'utilisation commerciale en question n'impose pas sa propre licence restrictive et respecte l'attribution libre des auteurs d'origine, et permette à nouveau de reproduire et redistribuer le produit acheté, y compris quand il a été amélioré. Oui, ça s'appelle du copyleft et ça se sigle par « SA » sur les créative commons. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Le 25 janvier 2012 18:09, Pieren pier...@gmail.com a écrit : 2012/1/25 Vincent de Chateau-Thierry v...@laposte.net: Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché aux ajouts de type subarea dans les relations Paris et Val de Marne, pour la simple raison que de tels ajouts se sont multipliés depuis hier : la Vienne : http://www.openstreetmap.org/browse/relation/7377 Poitou-Charente : http://www.openstreetmap.org/api/0.6/relation/8652 Seine-et-Marne : http://www.openstreetmap.org/api/0.6/relation/7383 etc, etc. Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il sera proposé. Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions alternatives (ne pas squatter les relations existantes, avant tout), ce qui ne réunit pas les conditions minimales d'une discussion. Un jour peut-être. Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des modifs semble d'accord pour une séparation des modèles dans des relations différentes à minima ? Tout d'abord je comprend très bien l'intérêt de la méthode de construction par niveaux indépendants qui favorise la modélisation par frontières. Je n'ai absolument rien à critiquer là-dessus. Cette méthode permet effectivement de construire 100% d'un niveau et de vérifier qu'il n'y a doublon des surfaces couvertes (intersections), ni surfaces oubliées pour un niveau donné. Oui effectivement elle permet de construire chaque niveau indépendamment de tous les autres. De même elle permet de détecter au sein d'un même niveau les frontières mitoyennes définies par des ways (ou boundary_segments si on les utilise, débat séparé) superposés: la méthode demandée veut qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au delà: on obtient une couche séparée pour ce niveau. Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec une couverture totale, pas de doublons, qu'elle est de qualité. Car on me dit d'utiliser une requête spaciale pour trouver les inclusions entre niveaux. En particulier, les frontières définies par un niveau sont aussi réutilisées pour définir les niveaux inférieurs: en travaillant sur un niveau donné, on peut très bien obtenir le niveau N 100% complet, et avoir tout cassé aux niveaux 1 à N-1... De même, il n'y a strictement rien avec le modèle qui utilise UNIQUEMENT les frontières pour recoller les niveaux entre eux: par exemple quel propriété boundary_level doit être mise dans les ways (ou boundary-segments si on les crée) ? Il n'y a aucune méthode pour vérifier que ces boundary_level sont corrects. De même, un ensemble de surfaces (définies par frontières) définies dans un niveau N+1 et qui devraient former une partition du niveau N, ne le font pas: la requête spacile échoue (et on se retrouve donc avec l'Ille-et-Vilaine qui n'est pas en Bretagne car des morceaux en dépassent. Le modèle avec *uniquement* les frontières ne permet pas le contrôle de cohérence. On aboutit alors aux aberrations produites par Nominatim (qui cherche alors une heuristique afin de déterminer quelle région contient le plus probablement l'Ille-et-Vilaine, basée sur les distances entre centroïdes, une heuristique qui est largement fausse et produit de nombreuses erreurs; on pourrait améliorer l'heuristique en calculant la surface (en mètres carrés ou autre unité de surface) commune, mais un tel calcul est bien plus lourd car cela suppose d'abord déterminer les intersections de surfaces polygonales, avant de calculer la surface par décomposition en triangles élémentaires: calcul très complexe que Nominatim ne fera sans doute jamais). Je ne veux pas dire qu'il faut supprimer les frontières: je veux garder les deux comme un outil de vérification mais aussi de consultation de la base de données ave des requêtes simples non spaciales. Ce que je défend reste la méthode de construction d'un niveau donné commençant d'abord par le modèle à frontières, qu'il font conserver dans les données. Si on représente la topologie des relations obtenues, on dessine un arbre des surfaces en commençant par tous les noeuds de l'arbre représentant les zones d'un même niveau, ces niveaux consituant l'axe horizontal de l'arbre hiérarchique virtuel. Maintenant on a toutes les couches horizontales créées, on les recolle sur le plan vertical en libellant explicitement les branches de l'arbre virtuel: c'est un ajout que l'on fait, on ne supprime pas les frontières du tout (les ways actuels, ou les boundary_segments proposés) ! Cet ajout évite d'avoir recours ensuite systémantiquement aux requêtes spaciales très lourdes et aux heuristiques pour gérer les ambiguités (cas des surfaces de niveaux différents qui se chevauchent géométriquement). Cette couche permet de vérifier la cohérence des niveaux différents entre eux. Je n'ai jamais milité pour la construction n'utilisant QUE le modèle par surface, mais je ne milite pas non plus pour celle n'utilisant QUE le modèle par
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Bonjour à tous, Cela fait un moment que je suis dépassé par cette discussion interminable. Est-ce qu'il ne serait pas intéressant que les différents protagonistes se rencontrent pour en discuter de vive-voix et avec des exemples à l'appui...? Romain Le 26 janvier 2012 09:33, Philippe Verdy verd...@wanadoo.fr a écrit : Le 25 janvier 2012 18:09, Pieren pier...@gmail.com a écrit : 2012/1/25 Vincent de Chateau-Thierry v...@laposte.net: Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché aux ajouts de type subarea dans les relations Paris et Val de Marne, pour la simple raison que de tels ajouts se sont multipliés depuis hier : la Vienne : http://www.openstreetmap.org/browse/relation/7377 Poitou-Charente : http://www.openstreetmap.org/api/0.6/relation/8652 Seine-et-Marne : http://www.openstreetmap.org/api/0.6/relation/7383 etc, etc. Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il sera proposé. Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions alternatives (ne pas squatter les relations existantes, avant tout), ce qui ne réunit pas les conditions minimales d'une discussion. Un jour peut-être. Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des modifs semble d'accord pour une séparation des modèles dans des relations différentes à minima ? Tout d'abord je comprend très bien l'intérêt de la méthode de construction par niveaux indépendants qui favorise la modélisation par frontières. Je n'ai absolument rien à critiquer là-dessus. Cette méthode permet effectivement de construire 100% d'un niveau et de vérifier qu'il n'y a doublon des surfaces couvertes (intersections), ni surfaces oubliées pour un niveau donné. Oui effectivement elle permet de construire chaque niveau indépendamment de tous les autres. De même elle permet de détecter au sein d'un même niveau les frontières mitoyennes définies par des ways (ou boundary_segments si on les utilise, débat séparé) superposés: la méthode demandée veut qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au delà: on obtient une couche séparée pour ce niveau. Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec une couverture totale, pas de doublons, qu'elle est de qualité. Car on me dit d'utiliser une requête spaciale pour trouver les inclusions entre niveaux. En particulier, les frontières définies par un niveau sont aussi réutilisées pour définir les niveaux inférieurs: en travaillant sur un niveau donné, on peut très bien obtenir le niveau N 100% complet, et avoir tout cassé aux niveaux 1 à N-1... De même, il n'y a strictement rien avec le modèle qui utilise UNIQUEMENT les frontières pour recoller les niveaux entre eux: par exemple quel propriété boundary_level doit être mise dans les ways (ou boundary-segments si on les crée) ? Il n'y a aucune méthode pour vérifier que ces boundary_level sont corrects. De même, un ensemble de surfaces (définies par frontières) définies dans un niveau N+1 et qui devraient former une partition du niveau N, ne le font pas: la requête spacile échoue (et on se retrouve donc avec l'Ille-et-Vilaine qui n'est pas en Bretagne car des morceaux en dépassent. Le modèle avec *uniquement* les frontières ne permet pas le contrôle de cohérence. On aboutit alors aux aberrations produites par Nominatim (qui cherche alors une heuristique afin de déterminer quelle région contient le plus probablement l'Ille-et-Vilaine, basée sur les distances entre centroïdes, une heuristique qui est largement fausse et produit de nombreuses erreurs; on pourrait améliorer l'heuristique en calculant la surface (en mètres carrés ou autre unité de surface) commune, mais un tel calcul est bien plus lourd car cela suppose d'abord déterminer les intersections de surfaces polygonales, avant de calculer la surface par décomposition en triangles élémentaires: calcul très complexe que Nominatim ne fera sans doute jamais). Je ne veux pas dire qu'il faut supprimer les frontières: je veux garder les deux comme un outil de vérification mais aussi de consultation de la base de données ave des requêtes simples non spaciales. Ce que je défend reste la méthode de construction d'un niveau donné commençant d'abord par le modèle à frontières, qu'il font conserver dans les données. Si on représente la topologie des relations obtenues, on dessine un arbre des surfaces en commençant par tous les noeuds de l'arbre représentant les zones d'un même niveau, ces niveaux consituant l'axe horizontal de l'arbre hiérarchique virtuel. Maintenant on a toutes les couches horizontales créées, on les recolle sur le plan vertical en libellant explicitement les branches de l'arbre virtuel: c'est un ajout que l'on fait, on ne supprime pas les frontières du tout (les ways actuels, ou les boundary_segments proposés) ! Cet ajout évite d'avoir recours ensuite systémantiquement aux
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Bonjour, Bla, bla bla. Tout ça pour vous rappeler l'origine d'OSM, ce qui explique l'existant. Une des bases philosophique d'OSM est l'ajout et la correction progressive. C'est la raison même des tags qui peuvent s'accumuler sur un élément afin d'ajouter de la précision dans sa définition : un premier contributeur indique une route, un second sa catégorie, un troisième son nom, etc. Je pense qu'il faut voir la méthode de définition des frontières sous le même angle : Un premier contributeur place une frontière (département, région, pays, commune), un second vient ensuite et ajoute un autre niveau... indépendamment du premier, mais en réutilisant les frontières déjà tracées. Effectivement un système pyramidal ne s'applique absolument pas à cette pratique : il faut commencer par la base puis remonter chaque couche sans en oublier une seule car l'ajout d'une nouvelle couche intermédiaire oblige à tout casser. Ce qui est clair, c'est que la méthode actuelle (des contours) évite les adhérences et facilite la maintenance (si si). Je peux casser une commune sans casser le département. Imaginez la course (et la surveillance) pour suivre 36000 communes pour que le pays soit intègre ! Mes 0.02 € (évidemment ma résistance au changement m'encourage à conserver la solution actuelle). -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Pour les rencontres, ça va être délicat là où je suis (les kilomètres...)... J'ai de bonnes raisons pour qu'on onclue simultanément les deux modèles. Particulièrement pour cette base de données qui est et restera en évolution permanente, et dans laquelle on aura toujours des lacunes. Avoir les deux permet de les combler au moins partiellement selon un axe vertical dans l'arbre (les surfaces hiérarchisées), ou selon un axe horizontal dans l'arbre (l'ensemble des frontières d'un même niveau). On peut progresser simultanément dans les deux directions pour aboutir à une convergence. Un moteur de rendu de tuiles n'a normalement besoin que des frontières, mais si des frontières (ways, boundary_segments, multilinestring en GIS: axe horizontal de l'arbre) manquent dans une relation, ou ne sont pas fermées, il peut alors de façon paliative (uniquement paliative) utiliser l'autre axe vertical (surfaces, subareas). Si on a une définition des subareas complètes (ou tout autre rôle qu'il serait utile de mettre si on veut renseigner plusieurs types de partitionnement de la surface mère) et pas encore de frontières, un moteur peur facilement remonter les frontières à la relation mère, et ajouter un FIXME pour vérifier cette frontière ajoutée automatiquement (uniquement dans le cas où la relation mère n'a pas de frontière définie, et uniquement si le rôle (subarea) le permet (mais une interdiction peut être mise en indiquant une propriété dans la relation mère, au cas où les subareas ne sont volontairement pas (ou pas encore) une partition complète de la surface définie par la relation mère (cas où il manque encore des subareas membres dans la relation mère). A mon avis un robot vérificateur ne doit pas faire cette remontée sans supervision humaine (il peut produire une liste, un humain ajoute des tags pour indiquer ce que le robot peut faire ou pas, le robot passe faire la modif demandée et revérifie en mettant à jour sa liste). De même, si on a une définition des frontières complètes dans la relation mère, un robot vérificateur peut faire la remontée des subareas avec le bon rôle en utilisant la définition des frontières trouvées par une recherche spaciale (attention: c'est seulement une heuristique! le contrôle humain reste nécessaire aussi, comme le prouve Nominatim qui fait ce type de recherches extrêmement lourdes à calculer et qui nécessite de charger et calculer un volume énorme de données depuis la base OSM). Le 26 janvier 2012 09:37, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour à tous, Cela fait un moment que je suis dépassé par cette discussion interminable. Est-ce qu'il ne serait pas intéressant que les différents protagonistes se rencontrent pour en discuter de vive-voix et avec des exemples à l'appui...? Romain Le 26 janvier 2012 09:33, Philippe Verdy verd...@wanadoo.fr a écrit : Le 25 janvier 2012 18:09, Pieren pier...@gmail.com a écrit : 2012/1/25 Vincent de Chateau-Thierry v...@laposte.net: Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché aux ajouts de type subarea dans les relations Paris et Val de Marne, pour la simple raison que de tels ajouts se sont multipliés depuis hier : la Vienne : http://www.openstreetmap.org/browse/relation/7377 Poitou-Charente : http://www.openstreetmap.org/api/0.6/relation/8652 Seine-et-Marne : http://www.openstreetmap.org/api/0.6/relation/7383 etc, etc. Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il sera proposé. Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions alternatives (ne pas squatter les relations existantes, avant tout), ce qui ne réunit pas les conditions minimales d'une discussion. Un jour peut-être. Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des modifs semble d'accord pour une séparation des modèles dans des relations différentes à minima ? Tout d'abord je comprend très bien l'intérêt de la méthode de construction par niveaux indépendants qui favorise la modélisation par frontières. Je n'ai absolument rien à critiquer là-dessus. Cette méthode permet effectivement de construire 100% d'un niveau et de vérifier qu'il n'y a doublon des surfaces couvertes (intersections), ni surfaces oubliées pour un niveau donné. Oui effectivement elle permet de construire chaque niveau indépendamment de tous les autres. De même elle permet de détecter au sein d'un même niveau les frontières mitoyennes définies par des ways (ou boundary_segments si on les utilise, débat séparé) superposés: la méthode demandée veut qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au delà: on obtient une couche séparée pour ce niveau. Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec une couverture totale, pas de doublons, qu'elle est de qualité. Car on me dit d'utiliser une requête spaciale pour trouver les inclusions entre niveaux. En particulier, les frontières
Re: [OSM-talk-fr] http://switch2osm.org/
Le 25/01/2012 16:56, Emilie Laffray a écrit : On Jan 25, 2012 1:48 PM, Philippe Pary phili...@cleo-carto.com mailto:phili...@cleo-carto.com wrote: Le 25/01/2012 14:17, Emilie Laffray a écrit : Ce soir la traduction française commencera On peut aider ? Oui J'en parlerai ce soir Nous sommes demain, peux-tu nous en dire plus ? :-) Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Open Data
Bonjour, je suis loin d'être spécialiste en la matière. J'ai l'impression au fil de ce que j'ai pu lire que la clause non commerciale peut se révèler totalement contre productive pour celui qui crée l'information, s'il se met en chasse des reutilisations commerciales. F. Ramm a donné l'exemple d'un wiki de la ville de Karlsuhe, totalement sclérosé par l'énergie depensée pour défendre son bon droit vis a vis de l'usage des donnees pour des activites lucratives. Le 26 janv. 2012 09:13, partir-en-vtt ad...@partir-en-vtt.com a écrit : L'argumentation me semble bien faible. On a plutôt l'impression que vous défendez votre beefsteak. -- View this message in context: http://gis.19327.n5.nabble.com/Open-Data-tp5380489p5432250.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] Festival À l’Ère Libre à Nancy le 6 avril 2012 (besoin de retours d'expérience pour tenue d'un stand)
Bonjour, Si vous êtes passés à côté de ce message, je fais appel à vos expériences passées ou à venir pour tenir un stand de présentation OSM. Merci. Romain Le 23 janvier 2012 21:45, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Suite à cet appel à projets http://erelibre.tuxfamily.org/ où j'ai proposé de présenter OSM, je suis donc convié à tenir un stand lors de ce festival qui se tiendra le 6 avril. Le festival mêle concerts et découverte de projets promouvant la culture libre. A priori, il n'y aurait pas plus de 5 stands afin que les visiteurs (200 en prévision) puissent avoir le temps de bien faire le tour de chaque. En pratique, en ce qui me concerne, je n'ai encore jamais eu à tenir un stand pour présenter OSM. Donc est-ce que vous pourriez m'aiguiller sur la façon d'organiser le stand et sur les besoins en matériel (je peux en demander aux organisateurs du festival), en support à présenter et à distribuer...? Et si le cœur vous en dit de venir faire un saut à Nancy, vous serez les bienvenus ;) Merci. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Festival À l’Ère Libre à Nancy le 6 avril 2012 (besoin de retours d'expérience pour tenue d'un stand)
Bonjour, Tu trouveras un début d'information là : http://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR/Groupes_de_travail/Communication http://wiki.openstreetmap.org/wiki/WikiProject_France/Support_Communication On fait encore souvent avec ce que l'on a. A mon avis il est important d'avoir une grande carte locale pour attirer l’œil. Ce qu'il manque le plus souvent c'est un grand logo d'OSM. Il est très profitable de prévoir un atelier, mais ça ne rentre peut être pas dans ton cadre. Frédéric Le 26 janvier 2012 10:25, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Si vous êtes passés à côté de ce message, je fais appel à vos expériences passées ou à venir pour tenir un stand de présentation OSM. Merci. Romain Le 23 janvier 2012 21:45, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Suite à cet appel à projets http://erelibre.tuxfamily.org/ où j'ai proposé de présenter OSM, je suis donc convié à tenir un stand lors de ce festival qui se tiendra le 6 avril. Le festival mêle concerts et découverte de projets promouvant la culture libre. A priori, il n'y aurait pas plus de 5 stands afin que les visiteurs (200 en prévision) puissent avoir le temps de bien faire le tour de chaque. En pratique, en ce qui me concerne, je n'ai encore jamais eu à tenir un stand pour présenter OSM. Donc est-ce que vous pourriez m'aiguiller sur la façon d'organiser le stand et sur les besoins en matériel (je peux en demander aux organisateurs du festival), en support à présenter et à distribuer...? Et si le cœur vous en dit de venir faire un saut à Nancy, vous serez les bienvenus ;) Merci. 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] Réflexions sur la modélisation dans osm des niveaux administratifs en france
2012/1/26 Philippe Verdy verd...@wanadoo.fr: il peut alors de façon paliative (uniquement paliative) utiliser l'autre axe vertical (surfaces, subareas). Dans tes arguments, tu parts toujours du principe que la relation boundary est parfois incomplète, ce qui induit ensuite Nominatim en erreur. Mais la même chose peut arriver dans le modèle surfacique. La relation peut manquer un subarea, une commune ou un département. Ou en avoir en trop. On ne peut jamais garantir l'intégrité des données. Et si un modèle diffère de l'autre (par exemple, une île qui serait dans l'un mais pas dans l'autre), il est impossible de savoir automatiquement qui a raison et qui a tord. Il faudra donc toujours passer par un contrôle manuel en cas de problème. Tu peux écrire des mails de 25 pages, tu n'as toujours pas démontré en quoi le modèle subarea n'est pas équivalent au modèle boundary actuel pour définir un multipolygone. Au contraire, comme d'autres l'ont déjà dit, le modèle surfacique ne marche que lorsque l'ensemble des subarea est défini. Hors, de nombreuses régions en France n'ont pas encore toutes leurs limites communales. C'est pour cela que le modèle boundary a toujours été préféré dans OSM jusqu'à aujourd'hui. Si tu ne peux pas vivre sans relations de type surfacique et pyramidal, soit, mais pas dans la même relation de type boundary. Si tu penses que les deux peuvent se compléter, rien ne t'empêche de sélectionner l'une ou l'autre en fonction de l'attribut type=* (les tags name et admin_level pouvant être identiques). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Open Data
Ce serait donc d'après vous plus par abandon (afin d'éviter de se ruiner la santé ou se ruiner tout court à traquer les fraudeurs) que par logique du non commercial que la clause NC n'a pas été mise en place ? -- View this message in context: http://gis.19327.n5.nabble.com/Open-Data-tp5380489p5432469.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] Open Data
A titre personnel c'est un aspect des choses, et qui a l'avantage d'aller dans le meme sens que cet autre aspect : l'usage commercial par un tiers ne me gene pas tant que cela ne vient pas en prendre la propriete. Je n'ai pas d'autre interet dans OSM qu'un divertissement qui peut apporter une valeur ajoutee vers le plus grand nombre. Le 26 janv. 2012 11:17, partir-en-vtt ad...@partir-en-vtt.com a écrit : Ce serait donc d'après vous plus par abandon (afin d'éviter de se ruiner la santé ou se ruiner tout court à traquer les fraudeurs) que par logique du non commercial que la clause NC n'a pas été mise en place ? -- View this message in context: http://gis.19327.n5.nabble.com/Open-Data-tp5380489p5432469.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] Parution de Bienvenue sur OpenStreetMap
Magnifique, nous allons nous en servir pour le personnel que nous allons former du CG84 le 3 février 2011. La partie POTLACH 2 nous sera particulièrement utile. Merci, Zimmy -- View this message in context: http://gis.19327.n5.nabble.com/Parution-de-Bienvenue-sur-OpenStreetMap-tp5430470p5432498.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] Re : Open Data
Si tu reprends la definition des 4 libertes qui definissent ce qui est dit libre il n y a aucun restrictions concernant la commercialisation. Donc si tu mets une clause de non commercialisation tu ne respectes plus ces 4 libertes. Openstreetmap se voulant libre il doit respecter ces 4 libertes. Stallman dit lui meme que logiciel libre ne veut pas dire non commercial Julien De : partir-en-vtt ad...@partir-en-vtt.com À : talk-fr@openstreetmap.org Envoyé le : Jeudi 26 janvier 2012 11h16 Objet : Re: [OSM-talk-fr] Open Data Ce serait donc d'après vous plus par abandon (afin d'éviter de se ruiner la santé ou se ruiner tout court à traquer les fraudeurs) que par logique du non commercial que la clause NC n'a pas été mise en place ? -- View this message in context: http://gis.19327.n5.nabble.com/Open-Data-tp5380489p5432469.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] Re : Festival À l’Ère Libre à Nancy le 6 avril 2012 (besoin de retours d'expérience pour tenue d'un stand)
Romain, Si cela t interesse j ai encore plein de flyers et de depliants OSM que Nicolas avait imprime pour les recontres du Logiciel Libre a Lyon. Si ca t interesse je peux t en envoyer pour t eviter d en reimprimer Julien De : Frédéric Rodrigo fred.rodr...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi 26 janvier 2012 10h33 Objet : Re: [OSM-talk-fr] Festival À l’Ère Libre à Nancy le 6 avril 2012 (besoin de retours d'expérience pour tenue d'un stand) Bonjour, Tu trouveras un début d'information là : http://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR/Groupes_de_travail/Communication http://wiki.openstreetmap.org/wiki/WikiProject_France/Support_Communication On fait encore souvent avec ce que l'on a. A mon avis il est important d'avoir une grande carte locale pour attirer l’œil. Ce qu'il manque le plus souvent c'est un grand logo d'OSM. Il est très profitable de prévoir un atelier, mais ça ne rentre peut être pas dans ton cadre. Frédéric Le 26 janvier 2012 10:25, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Si vous êtes passés à côté de ce message, je fais appel à vos expériences passées ou à venir pour tenir un stand de présentation OSM. Merci. Romain Le 23 janvier 2012 21:45, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Suite à cet appel à projets http://erelibre.tuxfamily.org/ où j'ai proposé de présenter OSM, je suis donc convié à tenir un stand lors de ce festival qui se tiendra le 6 avril. Le festival mêle concerts et découverte de projets promouvant la culture libre. A priori, il n'y aurait pas plus de 5 stands afin que les visiteurs (200 en prévision) puissent avoir le temps de bien faire le tour de chaque. En pratique, en ce qui me concerne, je n'ai encore jamais eu à tenir un stand pour présenter OSM. Donc est-ce que vous pourriez m'aiguiller sur la façon d'organiser le stand et sur les besoins en matériel (je peux en demander aux organisateurs du festival), en support à présenter et à distribuer...? Et si le cœur vous en dit de venir faire un saut à Nancy, vous serez les bienvenus ;) Merci. 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] La licence CC-Zero : une licence en faveur du domaine public.
A l'occasion de la journée du Domaine Public, nous vous proposons d'évoquer la licence Creative Commons Zero ( CC-0 ) *La licence CC-Zero : une licence en faveur du domaine public.* Utilisée telle une déclaration d'intention sur les ouvrages /Un monde sans copyright... et sans monopole (ed. Framabook) /et/Piratons la démocratie/(ed. ILV)), la licence Creative Commons Zero (CC-0) est un contrat qui traduit la volonté des auteurs dune oeuvre (scientifiques, enseignants, artistes, créateurs) souhaitant renoncer à leurs droits au profit du domaine public (ou, lorsque la loi ne leur permet pas, de les céder très largement). Toute personne est ainsi invitée à réutiliser librement leur création, quelque soit le but et sans aucune restriction de droit. Cette licence découle du positionnement en faveur du domaine public initié par Sciences Commons en 2007. Elle concède très largement les droits sur les données (et les bases de données) dans le but de permettre leur combinaison et diffusion sans entrave. Le projet communautaire Personal Genome ainsi que la région italienne du Piémont figurent ainsi parmi les premiers utilisateurs. Le travail de traduction fut réalisé courant 2010 par les associations VeniVidiLibri et Framasoft, dans leur objectif de vulgarisation et de promotion des licences libres (notamment au travers des licences GNU GPL, ODbL et Creative Commons). *La problématique* Déposer des travaux dans le domaine public est difficile, pour ne pas dire impossible, pour les personnes qui souhaitent contribuer à l'usage public avant l'expiration de leurs droits. Peu de juridictions offrent une telle possibilité et les législations varient d'une juridiction à l'autre (cession, date d'expiration, renoncement ). Aucun texte et aucune jurisprudence ne permettent à ce jour de donner de réponse certaine à la question de la validité d'un tel « domaine public » consenti. Néanmoins, la validité d'une mise volontaire dans le domaine public d'une oeuvre par son auteur reste très critiquée au regard du parallélisme des formes : seule la loi pouvant reprendre ce qu'elle a donné (à ce sujet, voir Jean (Benjamin), Option Libre. Du bon usage des licences libres, Paris, Framabook, déc. 2011, p26). Par ailleurs, certains droits (notamment celui d'être cité comme auteur -- droit de paternité) sont inaliénables et seront maintenus -- même à l'égard d' oeuvre du domaine public ou en situation de cession très large. *La solution CC0* Ainsi, la licence Creative Commons Zero (CC-0) agit en deux temps et traduit l'intention des créateurs d'abandonner tous leurs droits de copie et droits associés dans la limite offerte par la loi ou, lorsqu'un tel acte est impossible, d'opérer une cession non exclusive très large. De cette façon le domaine public et le domaine du libre se rejoignent pour ne faire qu'un. Conforme à l'esprit d'internet et du numérique, la licence Creative Commons Zero (CC-0) est un instrument universel et sans frontière. Au final, et bien que sa réception differera selon les législations en vigueur, cette licence est destinée à fournir le moyen le plus complet pour contribuer au domaine public quelque soit le pays concerné. [1] http://www.framablog.org/index.php/post/2010/10/15/proposition-traduction-licence-creative-commons-zero-1.0-cc0 Licence CC0 ( fr ) http://vvlibri.org/fr/licence/cc0/10/fr/legalcode Résumé de la CC0 ( fr ) http://vvlibri.org/fr/licence/cc0/10/fr Licence CC0 ( en ) http://creativecommons.org/publicdomain/zero/1.0/ Résumé de la CC0 ( en ) http://creativecommons.org/about/cc0 Faq CC0 ( en ) http://wiki.creativecommons.org/CC0_FAQ Option Libre : Du bon usage des licences libres ( fr ) http://framabook.org/option-libre-du-bon-usage-des-licences-libres Ce texte est sous licence CC-By-SA et inspiré fortement de ce texte _http://fr.issuepedia.org/index.php?title=Licence_CC0printable=yes_ http://fr.issuepedia.org/index.php?title=Licence_CC0printable=yes ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Open Data
Le 26 janvier 2012 11:16, partir-en-vtt ad...@partir-en-vtt.com a écrit : Ce serait donc d'après vous plus par abandon (afin d'éviter de se ruiner la santé ou se ruiner tout court à traquer les fraudeurs) que par logique du non commercial que la clause NC n'a pas été mise en place ? Bonjour, Ce que font les collectivités territoriales avec le mouvement Open data est comparable à ce que réalise OSM : mettre à dispo des données sous licence ODbL (ou assimilées) sans clause NC. Crois-tu que le mouvement de basculement vers OSM que l'on commence à observer aurait pu se produire avec une clause NC ? bien sur que non. A quel usage destiner des données libérées sous clause NC, à part la recherche. Ca limite beaucoup trop, et c'est nier que les acteurs économique sont parfois incontournables dans la diffusion de la culture libre. Donc il y aura des boîtes qui vont vivre sur les données, sur le dos des contributeurs OSM, sur les dos des collectivités, mais il y a aura aussi des boites pour les améliorer et ces ajouts profiterons à tous. Le mouvement Open data est avant tout portée par une l'idée politique de transparence vis à vis des concitoyens. La clause NC étant rédhibitoire pour le succès du mouvement, il reste la clause SA qui impose la réciprocité pour les acteurs économiques. En supprimant la clause SA on passait alors en domaine public et le pillage par les acteurs économiques aurait été plus difficile à gérer par les politiques vis à vis des concitoyens. Mais... Il y a un coût pour les collectivités et il est porté par elles-seules. Personnellement, pour plus de clarté en ces temps difficiles, j'aurai bien vu la mise en place d'une cagnotte pour chaque jeu de données: la collectivité fixe un prix à la libération, une cagnotte est mise en place, et quand le seuil des dons est atteint les données sont libérées pour tous. Plus embêtant je trouve: contrairement à OSM, il n'y a pas, à ma connaissance, de réciprocité dans les faits. les collectivités ne profitent pas des données corrigées ou étoffées. En gros ce n'est pas prévu ! Sur Nantes Métropole les fourmis importent dans OSM les adresses libérées, et notent laborieusement les points douteux, que l'on pointera sans doute ensuite sur place. Est-ce que Nantes Métropole va profiter un jour de ces données corrigées ? A+ BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Open Data
Le 26 janvier 2012 11:16, partir-en-vtt ad...@partir-en-vtt.com a écrit : Ce serait donc d'après vous plus par abandon (afin d'éviter de se ruiner la santé ou se ruiner tout court à traquer les fraudeurs) que par logique du non commercial que la clause NC n'a pas été mise en place ? Difficile de répondre pourquoi, à l'origine, le choix d'utilisation commercial possible a été choisi, il faudrait demander à steeve Coast. Au mieux, tu pourra avoir les avis des gens présents ici ;-) Il existe des projets libre non réutilisables commercialement donc, tout est possible, la majorité des gros cependant utilise cette autorisation, je suppose donc avant tout un mimétisme plutôt qu'un abandon. Suppositions : Steeve coast, pas avocat, dans son coin, démarre le projet avec 3 copains, 2 mois plus tard on lui demande : c'est quoi la licence ? Ben, heu... j'en sais rien moi, voyons : j'utilise et j'aime les logiciels libre et je veux faire un truc style wikipedia. Regardons : \autorisation commercial : OK\, alors pareil ! Je pense qu'il ne faut pas chercher plus loin. Pour ma part, jamais je n'aurais rejoins osm sans l'autorisation commercial de la licence. Je veux bien être philantrope jusqu'a un certain point, mais à un moment, il faut que je gagne ma croute. Et je compte (et j'utilise un peu) osm de manière commerciale, donc oui je donner à tous, mais après, j'ai bien l'intention de me servir du tout. Pour moi, cette clause est donc rédhibitoire -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Bonjour, De : sly (sylvain letuffe) On mercredi 25 janvier 2012, sly (sylvain letuffe) wrote: On mercredi 25 janvier 2012, Pieren wrote: Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des modifs semble d'accord pour une séparation des modèles dans des relations différentes à minima ? Je vote bien évidement pour le retour arrière sur ces relations comme la majorité des exprimés et laisse loisir à ceux qui défendent ce modèle de le créer, mais de manière séparé et isolé. Visiblement, la nuit été chargée en modification, je lui envoi un email pour lui demander s'il peut les retirer, ce sera plus simple car il sait quelles modifications il a fait. Pardon, je viens de lui envoyer le mail. Les éditions ont continué cette nuit, pour propager des subarea : http://www.openstreetmap.org/browse/changeset/10499268 Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était la teneur de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche de verdy_p. Ce que confirment ses propos ici même ce matin, je cite : La même relation représentant la région peut contenir à la fois la définition de ses frontières externes (définition horizontale dans l'arbre hiérarchique), et inclure la liste de ses membres (définition verticale dans l'arbre hiérarchique des niveaux) Pour avancer : * la discussion peut avantageusement se poursuivre sur la page ouverte (merci Sly) ici : http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Mod%C3%A8le _somme_de_surface_ou_mod%C3%A8le_fronti%C3%A8re Toutes les contributions y sont bienvenues, tant qu'on ne verse pas dans la logorrhée [1] * côté données en base, il faut procéder au rétablissement de la seule modélisation pour l'instant documentée [2] pour les limites administratives, et qui fait consensus. Je n'ai pas fait l'inventaire des relations, mais il y a potentiellement les niveaux région et département pour Pays-de-la-Loire, Poitou-Charentes et leurs départements, ainsi que Paris et le Val-de-Marne. Liste non exhaustive. Je peux me charger de les rétablir dans le courant de la journée, à moins que quelqu'un s'en charge avant, mais dans ce cas qu'il se signale ici, ça nous évitera d'emmêler nos pinceaux. merci vincent [1] : http://fr.wikipedia.org/wiki/Logorrh%C3%A9e [2] : http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives 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] Open Data
Bonjour Bruno, La question soulevée est d'actualité pour les programmes de Nantes Métropole et du Conseil Général de Loire Atlantique. C'est un débat qui s'est déjà posé auprès d'autres collectivités également: Comment intégrer l'enrichissement des données publiques par les contributeurs, notamment d'OSM qui sont les plus actifs sur la question actuellement ? La problématique vient du statut de la donnée. Pour que les collectivités les intègrent et apposent la notion donnée publique il faudrait qu'ils aillent vérifier à leur tour les retours (et que la donnée ait donc été collectée dans le cadre d'une mission de service publique). D'autres envisagent d'ajouter à leur fiches de données ouvertes un lien ou le fichier des correctifs en précisant la source (OSM). Nul doute qu'une solution technique et juridique finira par apparaître, c est en cours car évidemment ces données enrichies interpellent. Pour faire avancer sur le sujet sur Nantes, nous avions envisagé une mappingparty de vérification collective (OSM, Ville) Cela permettrait l'intégration de ces données vérifiées (selon les fréquences de mise à jour actuelles, qui varient selon les jeux). Mais il ne s'agit que d'une solution temporaire. Voilà un sujet à aborder pour la 1ere rencontre inter-administrations ouvertes le 1er février: comment intégrer les données enrichies ? Selon quelles modalités ? Sans réponse à cette question, le -SA n'aurait d'ailleurs aucune justification pour elles. Mais on va bien y arriver :) Si vous avez des suggestions, n'hésitez pas à les remonter sur le blog de libertic, nous avons lancé un appel. Bonne journée! Claire @libertic Le 26 janvier 2012 13:31, Bruno Cortial bruno.cort...@laposte.net a écrit : Le 26 janvier 2012 11:16, partir-en-vtt ad...@partir-en-vtt.com a écrit : Ce serait donc d'après vous plus par abandon (afin d'éviter de se ruiner la santé ou se ruiner tout court à traquer les fraudeurs) que par logique du non commercial que la clause NC n'a pas été mise en place ? Bonjour, Ce que font les collectivités territoriales avec le mouvement Open data est comparable à ce que réalise OSM : mettre à dispo des données sous licence ODbL (ou assimilées) sans clause NC. Crois-tu que le mouvement de basculement vers OSM que l'on commence à observer aurait pu se produire avec une clause NC ? bien sur que non. A quel usage destiner des données libérées sous clause NC, à part la recherche. Ca limite beaucoup trop, et c'est nier que les acteurs économique sont parfois incontournables dans la diffusion de la culture libre. Donc il y aura des boîtes qui vont vivre sur les données, sur le dos des contributeurs OSM, sur les dos des collectivités, mais il y a aura aussi des boites pour les améliorer et ces ajouts profiterons à tous. Le mouvement Open data est avant tout portée par une l'idée politique de transparence vis à vis des concitoyens. La clause NC étant rédhibitoire pour le succès du mouvement, il reste la clause SA qui impose la réciprocité pour les acteurs économiques. En supprimant la clause SA on passait alors en domaine public et le pillage par les acteurs économiques aurait été plus difficile à gérer par les politiques vis à vis des concitoyens. Mais... Il y a un coût pour les collectivités et il est porté par elles-seules. Personnellement, pour plus de clarté en ces temps difficiles, j'aurai bien vu la mise en place d'une cagnotte pour chaque jeu de données: la collectivité fixe un prix à la libération, une cagnotte est mise en place, et quand le seuil des dons est atteint les données sont libérées pour tous. Plus embêtant je trouve: contrairement à OSM, il n'y a pas, à ma connaissance, de réciprocité dans les faits. les collectivités ne profitent pas des données corrigées ou étoffées. En gros ce n'est pas prévu ! Sur Nantes Métropole les fourmis importent dans OSM les adresses libérées, et notent laborieusement les points douteux, que l'on pointera sans doute ensuite sur place. Est-ce que Nantes Métropole va profiter un jour de ces données corrigées ? A+ BrunoC ___ 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] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Les éditions ont continué cette nuit, pour propager des subarea : http://www.openstreetmap.org/browse/changeset/10499268 Bordel de p de foutage de gueule Ho, on a dit stop ! Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était la teneur de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche de verdy_p. Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces derniers temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la non information. La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war ne soit plus très loin. Et, comme OSM dispose de fonctions d'annulation extrêmement simples à utiliser et extrêmement efficace (j'ironise), on peut parier sur soit des dommage collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes encore. Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, ça ne m'amuse pas du tout, please, stop ! re moi, Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct, discuté correctement et on est tous d'accord sauf toi pour continuer. Il ne te semble pas que ta manière de faire ne peut que dégénérer ? Alors passons à autre chose, c'est triste, mais c'est une menace. Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande de bannir ton compte, et en attendant j'annule tous les changesets que tu fera par un logiciel et tout le monde y perdra du temps et ça ne peut que finir en EDIT war avec des pertes tristes. Comme en plus tu sembles t'y connaître en développement (d'après tes mails), et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde et potentiellement violent. Alors, s'il te plait, arrêtes. -- sly *** -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Le 26 janvier 2012 14:30, Hélène PETIT h...@free.fr a écrit : Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Il y a sûrement un équilibre à trouver entre une base avec uniquement des relations spatiales et l'ajout d'un peu de relationnel non spatial pour des objets spatialement très complexes à manipuler. Le volume de données à manipuler n'allant qu'en grandissant, ces informations non spatiales risques d'être de plus en plus utiles et nombreuses. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Tu veux parler d'un node avec le rôle label dans une relation d'admin_level=8 ? - à indiquer une position pour le nom de la commune sur le rendu des cartes À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Je ne vois pas trop l'intérêt moi non plus. En théorie, les tags d'une relation s'appliquent à ses membres, enfin c'est comme que je vois les choses. Même le boundary=administrative est redondant avec cette approche ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OSM WordPress mapping plugin - looking for help with French translations
Des volontaires pour aider à la traduction française d'un plugin Leaflet pour Wordpress ? -- Forwarded message -- From: i...@mapsmarker.com Date: 2012/1/26 Subject: [contact] [Informations sur l'association] OSM WordPress mapping plugin - looking for help with French translations To: cont...@openstreetmap.fr Robert Harm (i...@mapsmarker.com) a envoyé un message en utilisant le formulaire de contact suivant : http://www.openstreetmap.fr/**contacthttp://www.openstreetmap.fr/contact . Hello, my name is Robert Harm and I am the main developer of the new WordPress OSM mapping plugin Leaflet Maps Marker. This freely available plugin was released on Jan 1st 2012 and can be downloaded on www.mapsmarker.com (1500 downloads so far). It allows you to easily pin, organize show your favorite places through OpenStreetMap/WMTS, Google Maps/Earth (KML-Export), GeoJSON or Augmented-Reality browsers. A demo and a download link can be found on the plugin website. Why I am writing you: I received great feedback from users so far and the Chairman of OSM Japan even contributed a Japanese translation for the plugin. As I want to make this plugin usable to users not found of the English, German or Japanese language, I kindly ask you if you happen to know OSM guys/ladies could possible assist me translating the plugin in different languages like French or help to spread the word about my plugin which could really get more people into using OSM in my opinion. I am sure that this would not only benefit my plugin but also help OSM in general as it´s getting used much more often through the easy integration into the content management system Wordpress, which according to Wikipedia is used by over 14.7% of Alexa Internet's top 1 million websites and as of August 2011 powers 22% of all new websites.[5] WordPress is currently the most popular CMS in use on the Internet.[6][7] or according to http://en.wordpress.com/stats/ has been installed more than 70.700.000 times worldwide. Information on how to help with translations can be found at http://www.mapsmarker.com/**languages/http://www.mapsmarker.com/languages/ I´d really appreciate it, if you could spread this message to your appropriate OSM communication channels. Looking forward to your answer! Best regards from Vienna in Austria, Robert Harm -- Leaflet Maps Marker Plugin for Wordpress Pin, organize show your favorite places through OpenStreetMap/WMTS, Google Maps/Earth (KML), GeoJSON or Augmented-Reality browsers http://www.mapsmarker.com -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
2012/1/26 Hélène PETIT h...@free.fr: À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Le tag 'label' se retrouve dans plusieurs types de relations mais n'est pas encore exploité (à ma connaissance). L'idée, c'est pour résoudre des problèmes de rendu en forçant le placement du label (le texte name). Sinon, il arrive que ce label s'affiche dans des endroits incorrects (par exemple, lorsque la relation contient des exclaves et que le centroide se trouve à l'extérieur du multipolygone). À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Pour des raisons de retro-compatibilité, je suppose. C'est vrai qu'on pourrait s'en passer mais le logiciel de rendu - par exemple - devrait scanner l'ensemble des relations avant de pouvoir déterminer l'admin_level le plus haut (et donc le style à appliquer). En revanche, comme on le sait déjà, je ne suis pas partisan de mettre TOUS les tags dans les relations, pour des raisons de facilité de lecture pour un humain comme moi. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Une réponse sur un point de détail. Un way peut *n'être qu'une* limite administrative, auquel cas un tag boundary=administrative est le bienvenue . Si d'aventure on utilise une rivière ou une chemin/piste/route comme limite , seule la relation indiquera cet état de fait. ... mais il y a (ou il y a eu) des problèmes de rendu. -- View this message in context: http://gis.19327.n5.nabble.com/Modele-surface-Modele-frontiere-Bilan-tp5430900p5432929.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] OSM WordPress mapping plugin - looking for help with French translations
Jai une version en preparation, une francaise, pas une traduction... un plugin. Envoyé depuis mon Sony Ericsson Xperia arc Christian Quest cqu...@openstreetmap.fr a écrit : Des volontaires pour aider à la traduction française d'un plugin Leaflet pour Wordpress ? -- Forwarded message -- From: i...@mapsmarker.com Date: 2012/1/26 Subject: [contact] [Informations sur l'association] OSM WordPress mapping plugin - looking for help with French translations To: cont...@openstreetmap.fr Robert Harm (i...@mapsmarker.com) a envoyé un message en utilisant le formulaire de contact suivant : http://www.openstreetmap.fr/**contacthttp://www.openstreetmap.fr/contact . Hello, my name is Robert Harm and I am the main developer of the new WordPress OSM mapping plugin Leaflet Maps Marker. This freely available plugin was released on Jan 1st 2012 and can be downloaded on www.mapsmarker.com (1500 downloads so far). It allows you to easily pin, organize show your favorite places through OpenStreetMap/WMTS, Google Maps/Earth (KML-Export), GeoJSON or Augmented-Reality browsers. A demo and a download link can be found on the plugin website. Why I am writing you: I received great feedback from users so far and the Chairman of OSM Japan even contributed a Japanese translation for the plugin. As I want to make this plugin usable to users not found of the English, German or Japanese language, I kindly ask you if you happen to know OSM guys/ladies could possible assist me translating the plugin in different languages like French or help to spread the word about my plugin which could really get more people into using OSM in my opinion. I am sure that this would not only benefit my plugin but also help OSM in general as it´s getting used much more often through the easy integration into the content management system Wordpress, which according to Wikipedia is used by over 14.7% of Alexa Internet's top 1 million websites and as of August 2011 powers 22% of all new websites.[5] WordPress is currently the most popular CMS in use on the Internet.[6][7] or according to http://en.wordpress.com/stats/ has been installed more than 70.700.000 times worldwide. Information on how to help with translations can be found at http://www.mapsmarker.com/**languages/http://www.mapsmarker.com/languages/ I´d really appreciate it, if you could spread this message to your appropriate OSM communication channels. Looking forward to your answer! Best regards from Vienna in Austria, Robert Harm -- Leaflet Maps Marker Plugin for Wordpress Pin, organize show your favorite places through OpenStreetMap/WMTS, Google Maps/Earth (KML), GeoJSON or Augmented-Reality browsers http://www.mapsmarker.com -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ 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èle surface Modèle frontière : Bilan
2012/1/26 PhQ pierre.que...@sfr.fr: Si d'aventure on utilise une rivière ou une chemin/piste/route comme limite , seule la relation indiquera cet état de fait. ... mais il y a (ou il y a eu) des problèmes de rendu. A mettre en perspective avec la proposition multilinestring de Sly (http://wiki.openstreetmap.org/wiki/Relation:multilinestring) Alors le tag boundary, il est mis sur la relation multilinestring ou sur la relation boundary qui contient le multilinestring ? Dans le 2e cas, il devient encore plus difficile de voir que le way est aussi une frontière. A force de multiplier les relations et les structures pyramidales, il deviendra très difficile d'interpréter les données, surtout pour les non-experts. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Pour ma part, quand j'ai un doute, je regarde avec l'imagerie disponible. Il est vrai que dans le Puy de Dôme, j'ai la chance de disposer de Bing 2010-11 avec une précision de 30cm ainsi que CRAIG 2009. (même précision). Reste que c'est un boulot de ... dentelière. ( :) ) -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5432997.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] Import bâti = nettoyage des données cleo carto
On Thu, 26 Jan 2012 03:44:20 -0800 (PST), partir-en-vtt wrote: J'avais il y a quelque temps ouvert un sujet similaire: L'objectif était de proposer une moulinette pour nettoyer les erreurs de l'import du bâti. L'outil cleo-carto est extraordinaire pour générer les fichiers. Il me semble qu'il y a moins d'erreurs qu'avant. Pour autant tout n'est pas parfait et j'ai repéré que la majorité des erreurs sont : Que les bâtiments se superposent, Qu'il y a parfois des nœuds en doublons, le plugin validtor de josm propose des corrections automatique pour ca. Qu'il y a parfois une utilisation trop importante de nœuds, Qu'il y a des coupures dans les bâtiments qui sont inutiles. comment savoir si la coupure est justifié ou pas ? C'est le quatrième souci qui n'est pas facile à traiter. En effet, comment déterminer automatiquement si oui ou non il s'agit d'un artefact ? Faut-il fusionner les morceaux qui sont triangulaires et/ou qui ont une surface déterminée ? Je fais appel à vos idées. josm propose une selection par la surface. On peut sortir tous les building qui ont une surface = 0m^2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 26 janvier 2012 15:56, jul...@krilin.org a écrit : On Thu, 26 Jan 2012 03:44:20 -0800 (PST), partir-en-vtt wrote: J'avais il y a quelque temps ouvert un sujet similaire: L'objectif était de proposer une moulinette pour nettoyer les erreurs de l'import du bâti. L'outil cleo-carto est extraordinaire pour générer les fichiers. Il me semble qu'il y a moins d'erreurs qu'avant. Pour autant tout n'est pas parfait et j'ai repéré que la majorité des erreurs sont : Que les bâtiments se superposent, Qu'il y a parfois des nœuds en doublons, le plugin validtor de josm propose des corrections automatique pour ca. Qu'il y a parfois une utilisation trop importante de nœuds, Qu'il y a des coupures dans les bâtiments qui sont inutiles. comment savoir si la coupure est justifié ou pas ? Ce sont effectivement les erreurs les moins évidentes à identifier. De mon côté, je m'aide de la couche cadastrale, de l'imagerie Bing et en dernier ressort de l'observation sur le terrain mais tout ça c'est à la main donc long. C'est le quatrième souci qui n'est pas facile à traiter. En effet, comment déterminer automatiquement si oui ou non il s'agit d'un artefact ? Faut-il fusionner les morceaux qui sont triangulaires et/ou qui ont une surface déterminée ? Je fais appel à vos idées. josm propose une selection par la surface. On peut sortir tous les building qui ont une surface = 0m^2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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èle surface Modèle frontière : Bilan
Pour des raisons de retro-compatibilité, je suppose. C'est vrai qu'on pourrait s'en passer mais le logiciel de rendu - par exemple - devrait scanner l'ensemble des relations avant de pouvoir déterminer l'admin_level le plus haut (et donc le style à appliquer). Sauf erreur, C'est déjà ce qui se passe pour map...@osm.org ;-) d'une manière peu élégante d'ailleurs. Ce rendu réalise un rendu du chemin de frontière pour chaque relation dont il est membre, et en plus pour ces propres tags. Ce qui donne une infame couche très ampilée de tracés et le style a été fait pour que, par exemple, admin_level=2 fasse un rendu plus gros que tout les autres pour cache la misère. Exemples : http://www.openstreetmap.org/?lat=-79.863lon=-160.7434zoom=13layers=M En revanche, comme on le sait déjà, je ne suis pas partisan de mettre TOUS les tags dans les relations, pour des raisons de facilité de lecture pour un humain comme moi. à part pour le tag source=* moi c'est l'inverse, mais le sait aussi déjà ;-) D'autant que les progrès de josm sur la gestion des relations ont été énorme ces 2 dernières années -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
De : sly (sylvain letuffe) Les éditions ont continué cette nuit, pour propager des subarea : http://www.openstreetmap.org/browse/changeset/10499268 Bordel de p de foutage de gueule Ho, on a dit stop ! Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était la teneur de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche de verdy_p. Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces derniers temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la non information. La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war ne soit plus très loin. Et, comme OSM dispose de fonctions d'annulation extrêmement simples à utiliser et extrêmement efficace (j'ironise), on peut parier sur soit des dommage collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes encore. Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, ça ne m'amuse pas du tout, please, stop ! re moi, Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct, discuté correctement et on est tous d'accord sauf toi pour continuer. Il ne te semble pas que ta manière de faire ne peut que dégénérer ? Alors passons à autre chose, c'est triste, mais c'est une menace. Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande de bannir ton compte, et en attendant j'annule tous les changesets que tu fera par un logiciel et tout le monde y perdra du temps et ça ne peut que finir en EDIT war avec des pertes tristes. Comme en plus tu sembles t'y connaître en développement (d'après tes mails), et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde et potentiellement violent. Alors, s'il te plait, arrêtes. -- sly *** J'ai procédé dans ce changeset : http://www.openstreetmap.org/browse/changeset/10504679 à la suppression des membres de type subarea de quelques relations régionales, départementales, voire communales (Paris). Je ne garantis pas qu'il n'en reste pas ailleurs. C'est clairement triste d'en arriver à ce type d'action. Le message de Sly donnait pourtant une image claire de la situation et des risques encourus. En espérant qu'on passe rapidement (et sereinement :-) ) à autre chose ! 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] Cartographie d'un village viticole
Bonjour, J'ai commencé à cartographier le village de Brochon http://www.openstreetmap.org/?lat=47.23598lon=4.97588zoom=17layers=M, où j'habite. Il s'agit d'un village viticole. Tout d'abord je souhaite vos avis et remontées sur d'éventuelles bourdes et maladresses. Ensuite, j'ai commencé à tagger les parcelles viticoles. Le WIKI n'est pas très prolixe sur le sujet, je me suis donc contenté du nom de la parcelle et d'un landuse=vineyard. Cela me convient bien pour, par exemple, la parcelle Les Journaux L'ensemble de la parcelle étant constituée de vignes. Par contre pour une parcelle plus urbaine, comme le Meix Fringuet, je n'ai taggé que la zone plantée en vignes et non tout le quartier qui qui fait partie de cette parcelle dixit le cadastre. Et si on regarde plus au sud, la ville de Gevrey http://www.openstreetmap.org/?lat=47.225lon=4.98703zoom=15layers=M, les mêmes infos sont taggués avec place=locality et le nom de la parcelle. Un avis sur la bonne pratique ? -- Patrice HADOT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] conversion geofla des X_CENTROID de RGF93 en WGS84
Bonsoir, J'arrive un peu après la bataille, mais pour info, j'ai un plugin JOSM en développement qui fait tout ce boulot (rien d'autre à faire que d'ouvrir le shapefile depuis JOSM pour avoir un calque de données qui va bien). Je suis un peu réticent à distribuer le jar publiquement tant qu'on a pas ajouté la notion de calque privé dans JOSM [1], par crainte de voir de gros uploads de données brutes dans la base OSM, mais je peux distribuer par mail à ceux que ça intéresse :) Le plugin lit les formats CSV, KML/KMZ, Excel, ODS, shapefile ESRI et MapInfo, et pèse un peu plus de 2 Mo. [1] http://josm.openstreetmap.de/ticket/4922 Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Festival À l’Ère Libre à Nancy le 6 avril 2012 (besoin de retours d'expérience pour tenue d'un stand)
Alors oui ça m'intéresse! Sinon côté matériel, est-ce que vous avez des avis? Ce sont des étudiants d'une école d'informatique qui organisent ce festival donc il peuvent en mettre à disposition. Ce ne sera pas le lieu pour organiser un atelier. Pour une grande carte locale, si quelqu'un pouvait m'indiquer comment générer le fichier à imprimer...? Merci. Romain Le 26 janvier 2012 12:05, THEVENON Julien julien_theve...@yahoo.fr a écrit : Romain, Si cela t interesse j ai encore plein de flyers et de depliants OSM que Nicolas avait imprime pour les recontres du Logiciel Libre a Lyon. Si ca t interesse je peux t en envoyer pour t eviter d en reimprimer Julien -- *De :* Frédéric Rodrigo fred.rodr...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Jeudi 26 janvier 2012 10h33 *Objet :* Re: [OSM-talk-fr] Festival À l’Ère Libre à Nancy le 6 avril 2012 (besoin de retours d'expérience pour tenue d'un stand) Bonjour, Tu trouveras un début d'information là : http://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR/Groupes_de_travail/Communication http://wiki.openstreetmap.org/wiki/WikiProject_France/Support_Communication On fait encore souvent avec ce que l'on a. A mon avis il est important d'avoir une grande carte locale pour attirer l’œil. Ce qu'il manque le plus souvent c'est un grand logo d'OSM. Il est très profitable de prévoir un atelier, mais ça ne rentre peut être pas dans ton cadre. Frédéric Le 26 janvier 2012 10:25, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Si vous êtes passés à côté de ce message, je fais appel à vos expériences passées ou à venir pour tenir un stand de présentation OSM. Merci. Romain Le 23 janvier 2012 21:45, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Suite à cet appel à projets http://erelibre.tuxfamily.org/ où j'ai proposé de présenter OSM, je suis donc convié à tenir un stand lors de ce festival qui se tiendra le 6 avril. Le festival mêle concerts et découverte de projets promouvant la culture libre. A priori, il n'y aurait pas plus de 5 stands afin que les visiteurs (200 en prévision) puissent avoir le temps de bien faire le tour de chaque. En pratique, en ce qui me concerne, je n'ai encore jamais eu à tenir un stand pour présenter OSM. Donc est-ce que vous pourriez m'aiguiller sur la façon d'organiser le stand et sur les besoins en matériel (je peux en demander aux organisateurs du festival), en support à présenter et à distribuer...? Et si le cœur vous en dit de venir faire un saut à Nancy, vous serez les bienvenus ;) Merci. 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 ___ 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] Cartographie d'un village viticole
Salut, Bienvenue! Alors d'après ce que j'ai vu, la zone de vignes recouvre du résidentiel. Aide-toi plutôt de l'imagerie Bing pour bien caler les limites. Il y a des redondances d'information à la fois sur un nœud et un polygone (exemple du leisure=pitch, le château...) Le tracé des rues pourrait être affiné avec l'aide de Bing puisqu'elle est bien calée. De façon générale, ne pas négliger le tag source. Il manque le bâti du lycée. Est-ce que l'emprise du lycée est bien la même que celle indiquée pour le parc? Est-ce que l'orthographe de la Rue du *Huit* Mai est bien écrit comme tel? Le nom Eolienne est-il effectivement bien visiblement sur le terrain. Ne serait-ce pas plutôt un tag pour le rendu? Il y a par contre ce tag: http://wiki.openstreetmap.org/wiki/FR:Tag:generator:source%3Dwind De la même façon pour la mairie et l'école, il n'est pas nécessaire d'écrire de Brochon. Aussi, pour l'école, il vaudrait mieux appliquer un tag sur l'emprise totale (avec la cour) plutôt que sur chaque bâtiment individuel. Enfin la validation de JOSM indique quelques erreurs à corriger. Voilà déjà que quoi s'occuper ;) Il restera aussi les chemins dans les vignes avec http://wiki.openstreetmap.org/wiki/FR:Key:tracktype Romain Le 26 janvier 2012 18:31, Patrice Hadot patrice.ha...@gmail.com a écrit : Bonjour, J'ai commencé à cartographier le village de Brochonhttp://www.openstreetmap.org/?lat=47.23598lon=4.97588zoom=17layers=M, où j'habite. Il s'agit d'un village viticole. Tout d'abord je souhaite vos avis et remontées sur d'éventuelles bourdes et maladresses. Ensuite, j'ai commencé à tagger les parcelles viticoles. Le WIKI n'est pas très prolixe sur le sujet, je me suis donc contenté du nom de la parcelle et d'un landuse=vineyard. Cela me convient bien pour, par exemple, la parcelle Les Journaux L'ensemble de la parcelle étant constituée de vignes. Par contre pour une parcelle plus urbaine, comme le Meix Fringuet, je n'ai taggé que la zone plantée en vignes et non tout le quartier qui qui fait partie de cette parcelle dixit le cadastre. Et si on regarde plus au sud, la ville de Gevreyhttp://www.openstreetmap.org/?lat=47.225lon=4.98703zoom=15layers=M, les mêmes infos sont taggués avec place=locality et le nom de la parcelle. Un avis sur la bonne pratique ? -- Patrice HADOT ___ 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] Parution de Bienvenue sur OpenStreetMap
Le 26/01/2012 à 02:19:36 +1100 Emmanuel Dewaele emmanuel.dewa...@geovelo.fr a écrit Objet: [OSM-talk-fr] Parution de Bienvenue sur OpenStreetMap : Nous sommes fiers de vous présenter le premier livre en français sur OpenStreetMap, Un grand bravo pour ce travail ! et qui plus est, disponible sous licence libre (Creative Commons BY-SA). Sauf peut être l'image Google à la page 22 ?? PS: Ce projet est collaboratif, vous pouvez aussi y contribuer, on parlera très bientôt des futures évolutions du livre. Sinon, en bas de la page 84, le lien vers les mailing lists n'est pas très bien, car à cause du https FireFox fait un message d'avertissent. Le texte affiché et le lien ne sont pas identiques. Sinon, pour les GPS, le processus pour tel GPS en particulier est détaillé, mais une fois que l'on a le GPX entre les mains, il n'y est pas dit comment l'exploiter, l'envoyer sur le serveur ou pas. -- Cordialement Hendrik Oesterlin - Nouvelle-Calédonie ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le 26/01/2012 18:31, Patrice Hadot a écrit : Bonjour, J'ai commencé à cartographier le village de Brochon http://www.openstreetmap.org/?lat=47.23598lon=4.97588zoom=17layers=M, où j'habite. Il s'agit d'un village viticole. Tout d'abord je souhaite vos avis et remontées sur d'éventuelles bourdes et maladresses. Ensuite, j'ai commencé à tagger les parcelles viticoles. Le WIKI n'est pas très prolixe sur le sujet, je me suis donc contenté du nom de la parcelle et d'un landuse=vineyard. Cela me convient bien pour, par exemple, la parcelle Les Journaux L'ensemble de la parcelle étant constituée de vignes. Par contre pour une parcelle plus urbaine, comme le Meix Fringuet, je n'ai taggé que la zone plantée en vignes et non tout le quartier qui qui fait partie de cette parcelle dixit le cadastre. Et si on regarde plus au sud, la ville de Gevrey http://www.openstreetmap.org/?lat=47.225lon=4.98703zoom=15layers=M, les mêmes infos sont taggués avec place=locality et le nom de la parcelle. Un avis sur la bonne pratique ? Bonsoir Patrice, Quelques rappels sur l'organisation des données dans le cadastre français : - la parcelle (je vous fais grâce des subdivisions cadastrales) - le lieu-dit (place=locality) si tu descends un peu, vers Vosne-Romanée au hasard : http://osm.org/go/0A_BJkbCH- ;-) tu découvriras que ces lieux-dit correspondent parfois aux climats des apellations bourguignones si appréciées de nos palais et hélas, hors des capacités de nos bourses. - la sous-section (correspondant à la fameuse feuille cadastrale que toutes les fourmis qui mangent du cadastre raster connaissent bien ;-) - la section - la commune Ces couches sont emboitées les unes dans les autres et sont distinguées par des motifs ou des couleurs différentes (suivant que l'on est en raster ou vecteur). Cartographier les parcelles viticoles ©est MAL si tu entends tracer tous les détails des parcelles cadastrales qui ont une vocation (ou constatées d'usage) viticole et c'est pour cela que, j'espère, le wiki restera muet sur le sujet ; cartographier les climats est un plus pour la base, surtout quand ils correspondent à des délimitations de grand cru, de premier cru, etc... Pour moi, les lieux-dit sont un calque de toponymie, parfois associé à du bâti (constaté : le toponyme sert à nommer la rue desservant le lotissement, autrefois champs, prairies, bois,...), parfois associé à rien du tout (c'est du champ, de la vigne, un bois, basta), parfois, c'est aussi le nom d'un ancien village disparu. Bref une richesse trop souvent ignorée. Dans tous les cas, je tague en place=locality, sauf exception dûment constatée par mon expertise). Si ton objectif est de travailler plus le côté landuse=wineyard, il te faut découvrir le Recensement Parcellaire Graphique qui contient l'ensemble des déclarations de parcelles agricoles (avec leur usage dominant) dans le cadre de la PAC (Politique Agricole Commune). Ces données sont disponibles par département sous licence OL/LO sur le portail data.gouv.fr. Je n'ai pas encore eu le temps d'analyser ces lot de données, mais c'est la référence sur les pratiques culturales (au moins au niveau statitique). Pour ma part, j'attends la libération des données géocodées des délimitations des différentes AOC. Je crois que cela finira par arriver, mais pas sur qu'on ait une précision parcellaire ! Si ton objectif est de travailler sur les lieux-dit, abstrais-toi le plus souvent de l'occupation du sol sous-jacente et généralement postérieure. Denis, qui va aller se re-ballader dans la Grande Rue l'été prochain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://switch2osm.org/
2012/1/26 Philippe Pary phili...@cleo-carto.com Le 25/01/2012 16:56, Emilie Laffray a écrit : On Jan 25, 2012 1:48 PM, Philippe Pary phili...@cleo-carto.com mailto:phili...@cleo-carto.com wrote: Le 25/01/2012 14:17, Emilie Laffray a écrit : Ce soir la traduction française commencera On peut aider ? Oui J'en parlerai ce soir Nous sommes demain, peux-tu nous en dire plus ? :-) Excuse moi pour la lenteur de ma reponse. J'ai envoye un email a la personne en charge du site pour qu'il donne un acces :) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le jeudi 26 janvier 2012 21:12:05, DH a écrit : Pour ma part, j'attends la libération des données géocodées des délimitations des différentes AOC. Je crois que cela finira par arriver, mais pas sur qu'on ait une précision parcellaire ! Moi aussi je regarde du coté des AOC, j'ai trouvé ceci sur le site data.gouv.fr http://www.data.gouv.fr/content/search?SearchText=Aoc On as toutes les communes bénéficiant d'une AOC par contre dés que l'appelation ne fait partis que d'une patrtie de la commune il faut se référer aux texte de lois qui indique les numéros de parcelle. Cela ne pose pas de souci pour les AOC hors vin qui ne sont délimité que par des limites communales. Une autres source est la base de données européenne door http://ec.europa.eu/agriculture/quality/door/list.html?locale=fr qui liste toutes les aoc hors vins avec les liens vers les textes de lois. Pour les vins c'est la base de données e-bacchus http://ec.europa.eu/agriculture/markets/wine/e- bacchus/index.cfm?event=resultsPEccgislanguage=FR Le site de l'INAO est aussi a croisé avec ces deux site pour les AOC pas encore passé en AOP. Il reste a déterminé un façon de tagué tous cela (avec un modèle surface ou un modèle frontière :D ) sachant qu'au niveau du vignoble français les particularité sont grandes (différent niveau d'appellation qui différent d'une région viticole a l'autre) Librement Monsieur a ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le 26 janvier 2012 21:12, DH dhel...@free.fr a écrit : Cartographier les parcelles viticoles ©est MAL si tu entends tracer tous les détails des parcelles cadastrales qui ont une vocation (ou constatées d'usage) viticole et c'est pour cela que, j'espère, le wiki restera muet sur le sujet ; cartographier les climats est un plus pour la base, surtout quand ils correspondent à des délimitations de grand cru, de premier cru, etc... Pour moi, les lieux-dit sont un calque de toponymie, parfois associé à du bâti (constaté : le toponyme sert à nommer la rue desservant le lotissement, autrefois champs, prairies, bois,...), parfois associé à rien du tout (c'est du champ, de la vigne, un bois, basta), parfois, c'est aussi le nom d'un ancien village disparu. Bref une richesse trop souvent ignorée. Dans tous les cas, je tague en place=locality, sauf exception dûment constatée par mon expertise). Pour le vignoble alsacien j'essaie également de taguer les lieux-dit en place=locality. Je préférerais taguer les grand crus séparément en landuse=vineyard, mais sans la liste précise des parcelles classées, c'est mission impossible. Par exemple toutes les parcelles du lieu-dit cadastral Zinnkoepfle ne sont pas classées dans le Grand Cru Zinnkoepfle, qui en revanche s'étend sur d'autres lieux-dits. Pour avoir essayé de relever les limites précises de certaines appellations à partir des listes de parcelles, il faut en plus tenir compte des fusions et divisions de parcelles intervenues depuis plus de 20 ans (lorsque la demande de classement a été déposée). À cela il faut ajouter un brin d'imagination lorsque les parcelles ne sont classées que pour partie. Autant dire que c'est un énorme travail. En attendant, les lieux-dits permettent déjà de localiser bon nombre d'appellations. Matthias, qui attend également la libération des délimitations AOC... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le 26/01/2012 21:34, simon a écrit : Moi aussi je regarde du coté des AOC, j'ai trouvé ceci sur le site data.gouv.fr http://www.data.gouv.fr/content/search?SearchText=Aoc On as toutes les communes bénéficiant d'une AOC par contre dés que l'appelation ne fait partis que d'une patrtie de la commune il faut se référer aux texte de lois qui indique les numéros de parcelle. Cela ne pose pas de souci pour les AOC hors vin qui ne sont délimité que par des limites communales. Une autres source est la base de données européenne door http://ec.europa.eu/agriculture/quality/door/list.html?locale=fr qui liste toutes les aoc hors vins avec les liens vers les textes de lois. Pour les vins c'est la base de données e-bacchus http://ec.europa.eu/agriculture/markets/wine/e- bacchus/index.cfm?event=resultsPEccgislanguage=FR Merci Simon pour ces liens intéressants Donc, suivant bacchus, les appelations sont controlées par les textes législatifs nationaux (ici le *Décret du 24 janvier 2001 relatif à l'appellation d'origine contrôlée Alsace grand cru -*NOR: AGRP0001971D) Or que trouve-t-on à l'article 3 dudit décret ? Les plans de délimitation sont déposés à la mairie des communes intéressées. Ça m'intéressait si quelqu'un pouvait nous faire un compte-rendu d'une telle demande à sa mairie et de sa réponse éventuelle. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://switch2osm.org/
Le 26/01/2012 21:16, Emilie Laffray a écrit : 2012/1/26 Philippe Pary phili...@cleo-carto.com mailto:phili...@cleo-carto.com Le 25/01/2012 16:56, Emilie Laffray a écrit : On Jan 25, 2012 1:48 PM, Philippe Pary phili...@cleo-carto.com mailto:phili...@cleo-carto.com mailto:phili...@cleo-carto.com mailto:phili...@cleo-carto.com wrote: Le 25/01/2012 14:17, Emilie Laffray a écrit : Ce soir la traduction française commencera On peut aider ? Oui J'en parlerai ce soir Nous sommes demain, peux-tu nous en dire plus ? :-) Excuse moi pour la lenteur de ma reponse. J'ai envoye un email a la personne en charge du site pour qu'il donne un acces :) Excuse moi d'avoir trépigné :-) Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 26/01/2012 15:56, jul...@krilin.org a écrit : Que les bâtiments se superposent, Qu'il y a parfois des nœuds en doublons, le plugin validtor de josm propose des corrections automatique pour ca. Si quelqu'un veut se pencher sur le code de Qadastre (le mieux) ou créer un code/script pour nettoyer les fichiers cléo (pis aller), pas de soucis, je le mets en place. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le 26/01/2012 21:51, Matthias Dietrich a écrit : ... Pour avoir essayé de relever les limites précises de certaines appellations à partir des listes de parcelles, il faut en plus tenir compte des fusions et divisions de parcelles intervenues depuis plus de 20 ans (lorsque la demande de classement a été déposée). À cela il faut ajouter un brin d'imagination lorsque les parcelles ne sont classées que pour partie. Autant dire que c'est un énorme travail. +10 et il n'y a pas que les AOC qui sont concernées. On a le même problème pour les Zones Urbaines Sensibles et autres Réserves Naturelles Régionales. A ces époques reculées, l'État qui établissait ces périmètres avec une précision chirurgicale (à la parcelle quoi), fournissait les plans de délimitation des zones sur un fond Top25 !! Le meilleur : les données SIG des ces ZUS|Zone Franche|GPV ont la précision du 1:25.. Moi qui croyait que l'IGN était à moitié financé par l'Etat pour sa mission de service public, que le cadastre dépendait du Ministère des Finances, j'en suis plusieurs fois tombé de ma chaise. Finalement, c'est peut-être pour cette raison que l'Etalab est né et l'open data traduit en français. Je crois qu'on n'est pas au bout de nos surprises. Denis PS : je ne jette la pierre à personne, mes collègues de la fonction publique (actuels et anciens) font le maximum avec les moyens dont ils disposent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le jeu. 26 janv. 2012 à 20:13 +0100, Romain MEHUT a ecrit : [...] En plus des indications de Romain, pour le nommage des voies : Chemin rural n°25 dit de Lavaux (appellation du cadastre) devrait être balisé en : name = Chemin de Lavaux (sauf indication plus précise du terrain) ref = C 25 en particulier les dit de n'existent que sur le cadastre, jamais sur le terrain (panneaux indicateurs communaux). -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le jeudi 26 janvier 2012 22:00:40, DH a écrit : Le 26/01/2012 21:34, simon a écrit : Moi aussi je regarde du coté des AOC, j'ai trouvé ceci sur le site data.gouv.fr http://www.data.gouv.fr/content/search?SearchText=Aoc On as toutes les communes bénéficiant d'une AOC par contre dés que l'appelation ne fait partis que d'une patrtie de la commune il faut se référer aux texte de lois qui indique les numéros de parcelle. Cela ne pose pas de souci pour les AOC hors vin qui ne sont délimité que par des limites communales. Une autres source est la base de données européenne door http://ec.europa.eu/agriculture/quality/door/list.html?locale=fr qui liste toutes les aoc hors vins avec les liens vers les textes de lois. Pour les vins c'est la base de données e-bacchus http://ec.europa.eu/agriculture/markets/wine/e- bacchus/index.cfm?event=resultsPEccgislanguage=FR Merci Simon pour ces liens intéressants Donc, suivant bacchus, les appelations sont controlées par les textes législatifs nationaux (ici le *Décret du 24 janvier 2001 relatif à l'appellation d'origine contrôlée Alsace grand cru -*NOR: AGRP0001971D) Or que trouve-t-on à l'article 3 dudit décret ? Les plans de délimitation sont déposés à la mairie des communes intéressées. Ça m'intéressait si quelqu'un pouvait nous faire un compte-rendu d'une telle demande à sa mairie et de sa réponse éventuelle. Denis En fait dans les AOC il y as trois type de délimitation : -L'aire géographique, zone ou est récolté, vinifié, élaboré, élevé le vins (que l'on retrouve dans les textes de lois et c'est la zone la plus couramment représenté) -l'aire parcellaire, ce sont les parcelle sélectionne par l'INAO dans l'aire géographique d'où proviennent les raisins de l'appellation. Ces parcelles sont déposé au cadastre et consultable à la mairie de la commune. -L'aire de proximité immédiate : zone ou peuvent être vinifié et élaboré les vins. (cette zone est définie par dérogation). Pour la libération des données j'avais appellé l'INAO. Ils sont en train de géoréférencé toute les aires d'appelation et les parcelles mais le travail n'est pas encore fini et ils ne semblais vraiment motivé a partagé ces données. Après si dans OSM on arrive a créer une équipe pre a lire les textes de lois on peut commencé a refaire ce qu'ils sont en train de faire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.cleo-carto.org n° des départements
Le 17/01/2012 00:58, sly (sylvain letuffe) a écrit : Sur http://cadastre.cleo-carto.org serait il possible de rajouter le n° du département en plus de son nom dans le premier menu déroulant ? Ça serait utile pour les nuls comme moi en géographie ;-) Pour les départements, c'est fait. Je les ai mis à la fin par contre, tu aurais peut-être préféré au début ? Je trouve ça plus joli à la fin, mais c'est moins pratique. Mais c'est plus joli. Mais c'est moins pratique. Bref, n'hésite pas à me dire ce que tu en penses. Le numéro INSEE pour les communes dans le second menu déroulant serait aussi un plus Là, sauf erreur de ma part, je ne peux y arriver uniquement avec les données cadastres. Je peux m'en sortir en recoupant avec d'autres données, mais pour ce soir j'ai la flemme de le faire :-) Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le 26 janvier 2012 22:19, simon msr...@gmail.com a écrit : En fait dans les AOC il y as trois type de délimitation : -L'aire géographique, zone ou est récolté, vinifié, élaboré, élevé le vins (que l'on retrouve dans les textes de lois et c'est la zone la plus couramment représenté) -l'aire parcellaire, ce sont les parcelle sélectionne par l'INAO dans l'aire géographique d'où proviennent les raisins de l'appellation. Ces parcelles sont déposé au cadastre et consultable à la mairie de la commune. Oui mais le seul souci, c'est que pour les appellations de type 1er Cru ou Grand Cru, si on n'a pas l'aire parcellaire, on n'a pas grand chose. C'est valable également pour certaines micro-appellations. -L'aire de proximité immédiate : zone ou peuvent être vinifié et élaboré les vins. (cette zone est définie par dérogation). Pour la libération des données j'avais appellé l'INAO. Ils sont en train de géoréférencé toute les aires d'appelation et les parcelles mais le travail n'est pas encore fini et ils ne semblais vraiment motivé a partagé ces données. De ce que j'avais compris, ils ne font pas forcément le travail eux-même, mais passent parfois des partenariats avec certaines collectivités. Il me semble que le Conseil Général de Côte d'Or a effectué le géoréférencement des aires d'appellation du département pour le compte de l'INAO, avec en retour un droit de disposer des données. Et je n'ai pas non plus l'impression que la libération de leurs données soit une de leurs priorités. Après si dans OSM on arrive a créer une équipe pre a lire les textes de lois on peut commencé a refaire ce qu'ils sont en train de faire. Oui, ou une équipe qui voudra bien visiter toutes les mairies des communes situées dans les aires d'appellation, pour relever la définition parcellaire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.cleo-carto.org n° des départements
Le jeudi 26 janvier 2012 à 22:27 +0100, Philippe Pary a écrit : Le 17/01/2012 00:58, sly (sylvain letuffe) a écrit : Sur http://cadastre.cleo-carto.org serait il possible de rajouter le n° du département en plus de son nom dans le premier menu déroulant ? Ça serait utile pour les nuls comme moi en géographie ;-) Pour les départements, c'est fait. Je les ai mis à la fin par contre, tu aurais peut-être préféré au début ? Je trouve ça plus joli à la fin, mais c'est moins pratique. Mais c'est plus joli. Mais c'est moins pratique. tu ne serais pas un adepte du coca ? c'est bon oui mais ca pique ... Bref, n'hésite pas à me dire ce que tu en penses. Le numéro INSEE pour les communes dans le second menu déroulant serait aussi un plus Là, sauf erreur de ma part, je ne peux y arriver uniquement avec les données cadastres. Je peux m'en sortir en recoupant avec d'autres données, mais pour ce soir j'ai la flemme de le faire :-) Philippe ___ 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] http://cadastre.cleo-carto.org n° des départements
Le 26/01/2012 22:27, Philippe Pary a écrit : Le 17/01/2012 00:58, sly (sylvain letuffe) a écrit : Sur http://cadastre.cleo-carto.org serait il possible de rajouter le n° du département en plus de son nom dans le premier menu déroulant ? Ça serait utile pour les nuls comme moi en géographie ;-) Pour les départements, c'est fait. Je les ai mis à la fin par contre, tu aurais peut-être préféré au début ? Je trouve ça plus joli à la fin, mais c'est moins pratique. Mais c'est plus joli. Mais c'est moins pratique. Bref, n'hésite pas à me dire ce que tu en penses. Le numéro INSEE pour les communes dans le second menu déroulant serait aussi un plus Là, sauf erreur de ma part, je ne peux y arriver uniquement avec les données cadastres. Je peux m'en sortir en recoupant avec d'autres données, mais pour ce soir j'ai la flemme de le faire :-) Il y a peut-être une bidouille à tenter, car en regardant quelques codes de communes issus du cadastre, dans différents départements, les 3 derniers caractères semblent toujours être des chiffres, et ils ressemblent furieusement aux 3 derniers chiffres du code INSEE pour la même commune. quelques exemples pas du tout influencés par un autre fil..: -MONBAZILLAC côté cadastre : C1274 côté INSEE : 24274 -VAYRES côté cadastre : F4539 côté INSEE : 33539 -GEVREY CHAMBERTIN côté cadastre : B0295 côté INSEE : 21295 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Parution de Bienvenue sur OpenStreetMap
Le 26/01/2012 11:30, ZIMMY a écrit : Magnifique, nous allons nous en servir pour le personnel que nous allons former du CG84 le 3 février 2011. La partie POTLACH 2 nous sera particulièrement utile. Merci, Zimmy Bonsoir, C'est très positif, je suis preneur des retours d'expérience sur ce chapitre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le jeudi 26 janvier 2012 22:44:20, Matthias Dietrich a écrit : Le 26 janvier 2012 22:19, simon msr...@gmail.com a écrit : En fait dans les AOC il y as trois type de délimitation : -L'aire géographique, zone ou est récolté, vinifié, élaboré, élevé le vins (que l'on retrouve dans les textes de lois et c'est la zone la plus couramment représenté) -l'aire parcellaire, ce sont les parcelle sélectionne par l'INAO dans l'aire géographique d'où proviennent les raisins de l'appellation. Ces parcelles sont déposé au cadastre et consultable à la mairie de la commune. Oui mais le seul souci, c'est que pour les appellations de type 1er Cru ou Grand Cru, si on n'a pas l'aire parcellaire, on n'a pas grand chose. C'est valable également pour certaines micro-appellations. Ah oui en fonction des régions il donne ou non les numéro de parcelle (sur St émilion cela semble bon mais pas sur l'alsace :)) -L'aire de proximité immédiate : zone ou peuvent être vinifié et élaboré les vins. (cette zone est définie par dérogation). Pour la libération des données j'avais appellé l'INAO. Ils sont en train de géoréférencé toute les aires d'appelation et les parcelles mais le travail n'est pas encore fini et ils ne semblais vraiment motivé a partagé ces données. De ce que j'avais compris, ils ne font pas forcément le travail eux-même, mais passent parfois des partenariats avec certaines collectivités. Il me semble que le Conseil Général de Côte d'Or a effectué le géoréférencement des aires d'appellation du département pour le compte de l'INAO, avec en retour un droit de disposer des données. Et je n'ai pas non plus l'impression que la libération de leurs données soit une de leurs priorités. Après si dans OSM on arrive a créer une équipe pre a lire les textes de lois on peut commencé a refaire ce qu'ils sont en train de faire. Oui, ou une équipe qui voudra bien visiter toutes les mairies des communes situées dans les aires d'appellation, pour relever la définition parcellaire. Ou peut être voir du coté des associations de producteur. Si j'ai le temps lundi j'irais faire un tours dans les mairie de Vouvray, Montlouis ... ___ 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] Cartographie d'un village viticole
Le jeudi 26 janvier 2012 18:31:13 Patrice Hadot a écrit : Ensuite, j'ai commencé à tagger les parcelles viticoles. Un jour on aura un rendu comme sur ce site \o/ http://www.vinogeo.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.cleo-carto.org n° des départements
Le 26/01/2012 23:00, Vincent de Chateau-Thierry a écrit : Le 26/01/2012 22:27, Philippe Pary a écrit : Le 17/01/2012 00:58, sly (sylvain letuffe) a écrit : Sur http://cadastre.cleo-carto.org serait il possible de rajouter le n° du département en plus de son nom dans le premier menu déroulant ? Ça serait utile pour les nuls comme moi en géographie ;-) Pour les départements, c'est fait. Je les ai mis à la fin par contre, tu aurais peut-être préféré au début ? Je trouve ça plus joli à la fin, mais c'est moins pratique. Mais c'est plus joli. Mais c'est moins pratique. Bref, n'hésite pas à me dire ce que tu en penses. Le numéro INSEE pour les communes dans le second menu déroulant serait aussi un plus Là, sauf erreur de ma part, je ne peux y arriver uniquement avec les données cadastres. Je peux m'en sortir en recoupant avec d'autres données, mais pour ce soir j'ai la flemme de le faire :-) Il y a peut-être une bidouille à tenter, car en regardant quelques codes de communes issus du cadastre, dans différents départements, les 3 derniers caractères semblent toujours être des chiffres, et ils ressemblent furieusement aux 3 derniers chiffres du code INSEE pour la même commune. quelques exemples pas du tout influencés par un autre fil..: -MONBAZILLAC côté cadastre : C1274 côté INSEE : 24274 -VAYRES côté cadastre : F4539 côté INSEE : 33539 -GEVREY CHAMBERTIN côté cadastre : B0295 côté INSEE : 21295 Bonne remarque. Quelques contrôles confirment ça : essayons pour voir. Je m'y mets dès que ma flemme se lève. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Non, désolé, le stop concernait le seul test du bounary_segment. J'avais demandé des explications sur ce qui ne fonctionnait pas, et je n'en ai pas ajoutés. Pour le reste je n'ai strictement rien cassé avec les subareas, et personne ne l'a démontré. OK j'ai fait un test, mais il n'a pas été un échec. Ce n'est QUE maintenant qu'on me dit stop sur les subareas et que vous les enlevez. C'est dommage, car vous les enlevez sans avoir signalé quel problème était causé. Alors que j'ai voulu montrer les problèmes que causent leur absence. JAMAIS je n'ai voulu supprimer des frontières, je les ai toutes laissées (j'ai fait un seul test uniquement du boundary_segment sur la côte nord de l'Ille-et-Vilaine et j'attendais de voir le résultat, car il y avait déjà des boundary_segments incohérents et très difficiles à mettre à jour, pour la frontière française, que le serveur peine énormément à gérer et que chaque édition locale sur la côte nécessite un chargement énorme de données et de pénibles synchonisations de dizaines de milliers de noeuds: les boundary_segments de la France sont trop acutellement beaucoup longs, et même si on décide de garder les ways pour les côtes de l'Ille-et-Vilaine, les segments de frontière frontçaise par départements sont à privilégier au niveau de la zone France, afin de soulager le travail: c'est un redécoupage plus fin qui ne change pas le modèle actuel pour la France; mais il reste que le problème est aussi ardu pour la Bretagne). Je ne vois pas où est « l'editwar » pour des propriétés ajoutées (les subareas documentés) qui n'ôte rien à la modélisation dans la direction horizontale que je n'ai JAMAIS voulu supprimer. A côté de cela, on ajoute des tas d'autres tags et propriétés qui sont ignorées par un logiciel ou un autre, et ces subareas ne sont que des propriétés de plus, même si vous voulez continuer à travailler uniquement au niveau frontières (malgré l'intérêt de l'autre direction modélisation par surfaces qui assure aussi une meilleure compatibilité avec des sources externes qui peinent énormément à intégrer leurs données). JE ne vais pas en remettre (attention j'ai une sauvegarde en cours et des conflits de sauvegarde, sur des modifs non encore fermées à l'heure actuelle: j'en profite pour supprimer les subareas qui y sont encore, sur la Mayenne: mon intention n'est pas de les remettre, mais je viens seulement de lire cet ORDRE, même si je ne comprends pas votre réaction aussi virulente). Le 26 janvier 2012 17:42, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : sly (sylvain letuffe) Les éditions ont continué cette nuit, pour propager des subarea : http://www.openstreetmap.org/browse/changeset/10499268 Bordel de p de foutage de gueule Ho, on a dit stop ! Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était la teneur de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche de verdy_p. Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces derniers temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la non information. La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war ne soit plus très loin. Et, comme OSM dispose de fonctions d'annulation extrêmement simples à utiliser et extrêmement efficace (j'ironise), on peut parier sur soit des dommage collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes encore. Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, ça ne m'amuse pas du tout, please, stop ! re moi, Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct, discuté correctement et on est tous d'accord sauf toi pour continuer. Il ne te semble pas que ta manière de faire ne peut que dégénérer ? Alors passons à autre chose, c'est triste, mais c'est une menace. Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande de bannir ton compte, et en attendant j'annule tous les changesets que tu fera par un logiciel et tout le monde y perdra du temps et ça ne peut que finir en EDIT war avec des pertes tristes. Comme en plus tu sembles t'y connaître en développement (d'après tes mails), et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde et potentiellement violent. Alors, s'il te plait, arrêtes. -- sly *** J'ai procédé dans ce changeset : http://www.openstreetmap.org/browse/changeset/10504679 à la suppression des membres de type subarea de quelques relations régionales, départementales, voire communales (Paris). Je ne garantis pas qu'il n'en reste pas ailleurs. C'est clairement triste d'en arriver à ce type d'action. Le message de Sly
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Mon dernier changset en contient encore, mais dans mes données locales, je les ai toutes supprimées, et je suis en train de mettre à jour les conflits éventuels pour qu'ils ne soient plus là: ceci terminé, il ne devrait plus en rester. Ce n'est pas mon intention de faire un edit war. Je trouve dommage que vous ne considériez pas cela comme une métadonnée qui ne change rien à vos méthodes, et qui pourant facilite le contrôle d'adhérence des frontières entre les niveaux (un contrôle actuellement totalement inexistant dans OSM, et qui a conduit à des aberrhations dans les tests d'inclusion d'une surface dans une autre, que je me proposais de résoudre facilement avec ces métadonnées qui facilitent ce contrôle, même si vous n'en avez pas besoin pour travailler sur les frontières d'un niveau donné. Sans le contrôle d'adhérence, impossible de corriger les résultats farfelus (très nombreux) produits par l'heuristique de Nominatim (et ailleurs...). Je voudrais que vous vous en rendiez compte ! Franchement je ne vois pas du tout ce qui vous gênait dans ces métadonnées (les quelques membres supplémentaires de rôle subarea). Et impossible d'intégrer des métadonnées externes hiérachisées qui ne trouvent pas les zones s'il n'y a pas d'adhérence avec le SEUL modèle spacial. Par exemple, le récent import des noms de communes bretonnes n'a pas trouvé ces tas de communes qui pourtant étaient sur les cartes. Difficile de mettre à jour des chiffres de population, des données administratives à l'échelle d'un pays (trop de données à charger depuis le serveur qui refuse alors les requêtes trop volumineuses). Je vous ai expliqué l'intérêt, sincèrement c'était des métadonnées très utiles aussi à contrôler (et corriger) la cohérence des cartes des différents niveaux, et qui évitent d'importer des données cartographiques au mauvais endroit ou de créer des objets en doublon (qui alors se superposent et compliquent la tâche des éditeurs). Le 26 janvier 2012 17:42, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : sly (sylvain letuffe) Les éditions ont continué cette nuit, pour propager des subarea : http://www.openstreetmap.org/browse/changeset/10499268 Bordel de p de foutage de gueule Ho, on a dit stop ! Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était la teneur de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche de verdy_p. Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces derniers temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la non information. La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war ne soit plus très loin. Et, comme OSM dispose de fonctions d'annulation extrêmement simples à utiliser et extrêmement efficace (j'ironise), on peut parier sur soit des dommage collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes encore. Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, ça ne m'amuse pas du tout, please, stop ! re moi, Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct, discuté correctement et on est tous d'accord sauf toi pour continuer. Il ne te semble pas que ta manière de faire ne peut que dégénérer ? Alors passons à autre chose, c'est triste, mais c'est une menace. Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande de bannir ton compte, et en attendant j'annule tous les changesets que tu fera par un logiciel et tout le monde y perdra du temps et ça ne peut que finir en EDIT war avec des pertes tristes. Comme en plus tu sembles t'y connaître en développement (d'après tes mails), et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde et potentiellement violent. Alors, s'il te plait, arrêtes. -- sly *** J'ai procédé dans ce changeset : http://www.openstreetmap.org/browse/changeset/10504679 à la suppression des membres de type subarea de quelques relations régionales, départementales, voire communales (Paris). Je ne garantis pas qu'il n'en reste pas ailleurs. C'est clairement triste d'en arriver à ce type d'action. Le message de Sly donnait pourtant une image claire de la situation et des risques encourus. En espérant qu'on passe rapidement (et sereinement :-) ) à autre chose ! 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
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Le jeudi 26 janvier 2012 23:08:18, Philippe Verdy a écrit : Non, désolé, le stop concernait le seul test du bounary_segment. Alors je m'excuse si je n'ai pas été clair, mais maintenant que tout est clarifié tout va bien, l'incident est clos concernant les role:subarea, on n'en veut pas. Ce qui n'empêche pas, comme on a pu le dire que tu créés, si tu le veux, des relations différentes, avec un autre type=bidule sur le modèle subarea. Pour les type=boundary_segment, pour l'instant, restons avec les contours de la france (contraintes techniques obligent) nous passerons peut-être, ultérieurement à des niveau régions et départements. (...) Sans vouloir te vexer, ni m'abaisser de trop à m'attarder sur la forme de tes emails, tu as souvent des points valident à avancer, des idées pertinentes à défendre, que tu noies dans un terrible flot trop long de paroles qui répète plusieurs fois ce que tu as déjà dis et finissent à mon avis par desservir les idées qui s'y cachent. Ce qui est dommage. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Le 26 janvier 2012 10:57, Pieren pier...@gmail.com a écrit : 2012/1/26 Philippe Verdy verd...@wanadoo.fr: il peut alors de façon paliative (uniquement paliative) utiliser l'autre axe vertical (surfaces, subareas). Dans tes arguments, tu parts toujours du principe que la relation boundary est parfois incomplète, ce qui induit ensuite Nominatim en erreur. Mais la même chose peut arriver dans le modèle surfacique. La relation peut manquer un subarea, une commune ou un département. Ou en avoir en trop. On ne peut jamais garantir l'intégrité des données. Et si un modèle diffère de l'autre (par exemple, une île qui serait dans l'un mais pas dans l'autre), il est impossible de savoir automatiquement qui a raison et qui a tord. Il faudra donc toujours passer par un contrôle manuel en cas de problème. Tu peux écrire des mails de 25 pages, tu n'as toujours pas démontré en quoi le modèle subarea n'est pas équivalent au modèle boundary actuel pour définir un multipolygone. Au contraire, comme d'autres l'ont déjà dit, le modèle surfacique ne marche que lorsque l'ensemble des subarea est défini. C'est faux ! On peut très bien créer une nouvelle relation de frontières avec un membre subarea ajouté à la zone plus grande, sans avoir pour l'instant l'ensemble de ses frontières, mais par exemple juste un admin_center. On la crée rapidement, avec les autres métadonnées, on ajoute un fixme pour les frontières manquantes (ou approximatives à redessiner avec une source cadastrale). Cela ne remplace PAS le tracé des frontières. Et jamais je n'ai défendu cette position. Hors, de nombreuses régions en France n'ont pas encore toutes leurs limites communales. Justement c'est le cas en Mayenne, où il manquait aussi les 3 arrondissements que je suis en train d'ajouter SANS supprimer aucune frontière. Les frontières restent là, je n'ai rien changé là-dessus. C'est pour cela que le modèle boundary a toujours été préféré dans OSM jusqu'à aujourd'hui. Si tu ne peux pas vivre sans relations de type surfacique et pyramidal, soit, mais pas dans la même relation de type boundary. Si tu penses que les deux peuvent se compléter, rien ne t'empêche de sélectionner l'une ou l'autre en fonction de l'attribut type=* (les tags name et admin_level pouvant être identiques). Pas dans la même relation ? Tout l'intérêt est perdu car cela revient à dédoubler toutes les relations filles, sans permettre de mettre un seul lien avec l'autre relation par frontières, alors qu'il suffit d'ajouter dans la relation mère UN SEUL membre par relation contenue dans une autre. Le volume de données est négligeable au regard des données des frontières: pas de relation en double portant les mêmes noms, les mêmes références INSEE, NUTS ou autre, aucun besoin de modifier les frontières ou de les doublonner. Ta solution serait pire car alors il y aurait ambuiguité sur la relation à mettre à jour par des outils de recherche externe, si on trouve deux relations avec le même type, les mêmes tags (de référence) et les mêmes admin_level ! Alors que cela désigne strictement le même objet... Où est le modèle relationnel dans tout ça ??? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Le 26/01/2012 23:08, Philippe Verdy a écrit : JAMAIS je n'ai voulu supprimer des frontières, je les ai toutes laissées (j'ai fait un seul test uniquement du boundary_segment sur la côte nord de l'Ille-et-Vilaine et j'attendais de voir le résultat, car il y avait déjà des boundary_segments incohérents et très difficiles à mettre à jour, pour la frontière française, que le serveur peine énormément à gérer et que chaque édition locale sur la côte nécessite un chargement énorme de données et de pénibles synchonisations de dizaines de milliers de noeuds: les boundary_segments de la France sont trop acutellement beaucoup longs, et même si on décide de garder les ways pour les côtes de l'Ille-et-Vilaine, les segments de frontière frontçaise par départements sont à privilégier au niveau de la zone France, afin de soulager le travail: c'est un redécoupage plus fin qui ne change pas le modèle actuel pour la France; mais il reste que le problème est aussi ardu pour la Bretagne). Le fait de splitter les limites côtières (et uniquement elles) françaises en relations boundary_segment à raison d'une relation par département, a déjà été discuté ici et admis. J'avais proposé de m'en occuper et je ne l'ai pas fait : http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/037663.html Tu peux prendre le relais. À noter qu'il existe déjà un boundary_segment pour les Côtes d'Armor : http://www.openstreetmap.org/browse/relation/1846740 créé de mon côté en guise de test, et un autre créé par toi pour l'Ille-et-Vilaine, et auquel je n'ai pas touché en réparant le contour de ce département hier : http://www.openstreetmap.org/browse/relation/1979939 Donc pour la Bretagne, on ne part pas de rien. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Le 26 janvier 2012 23:49, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 26/01/2012 23:08, Philippe Verdy a écrit : JAMAIS je n'ai voulu supprimer des frontières, je les ai toutes laissées (j'ai fait un seul test uniquement du boundary_segment sur la côte nord de l'Ille-et-Vilaine et j'attendais de voir le résultat, car il y avait déjà des boundary_segments incohérents et très difficiles à mettre à jour, pour la frontière française, que le serveur peine énormément à gérer et que chaque édition locale sur la côte nécessite un chargement énorme de données et de pénibles synchonisations de dizaines de milliers de noeuds: les boundary_segments de la France sont trop acutellement beaucoup longs, et même si on décide de garder les ways pour les côtes de l'Ille-et-Vilaine, les segments de frontière frontçaise par départements sont à privilégier au niveau de la zone France, afin de soulager le travail: c'est un redécoupage plus fin qui ne change pas le modèle actuel pour la France; mais il reste que le problème est aussi ardu pour la Bretagne). Le fait de splitter les limites côtières (et uniquement elles) françaises en relations boundary_segment à raison d'une relation par département, a déjà été discuté ici et admis. J'avais proposé de m'en occuper et je ne l'ai pas fait : http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/037663.html Tu peux prendre le relais. À noter qu'il existe déjà un boundary_segment pour les Côtes d'Armor : http://www.openstreetmap.org/browse/relation/1846740 créé de mon côté en guise de test, et un autre créé par toi pour l'Ille-et-Vilaine, et auquel je n'ai pas touché en réparant le contour de ce département hier : http://www.openstreetmap.org/browse/relation/1979939 Donc pour la Bretagne, on ne part pas de rien. OK, donc je vais continuer à ajouter les splits départementaux, pour qu'enfin on puisse remplacer les segments trop grands de la frontière française (pour l'instant ils restent là), par les segments départementaux. Mais que faire alors de la frontière de la région Bretagne elle-même (très compliqué ?) peut-on la splitter en utilisant alors les segments départementaux qu'on aura créés ?? Dernier point: je ne suis pas le seul à vouloir utiliser les subareas (même si on n'en a pas besoin pour dessiner une surface): regardez par exemple la Belgique et l'Espagne, qui les utilisent comme métadonnées intégrées directement dans les mêmes relations de frontières (et PAS dans des relations différentes). Je n'ai jamais nié l'intérêt de la définition par frontières (quoique l'absence de support partout des boundary_segments pose encore problème). Je ne l'ai jamais remise en cause, pas même lors de mon essai d'utiliser le boundary_segment de la côte nord l'Ille-et-Vilaine, au lieu de dupliquer les ways comme on ne fait encore, avec toutes les incohérences que cela génère quand les différents niveaux ne sont pas mis en jour en même temps, ce qui n'est franchement pas facile à faire pour les hauts niveaux qui contiennent des centaines de ways désordonnées et anonymes, raison pour laquelle je me bat en permanence pour essayer de les faire apparaitre comme formant des boucles complètes, afin d'identifier les ways à ajouter ou supprimer de la relation mère !) On est pas les seuls en France à avoir ces incohérences (les Allemands se plaignent, et les Anglais aussi surement, mais je n'ai pas regardé si eux aussi utilisaient les subareas pour faciliter la maintenance des ways de toutes les relations de niveau inférieur quand une petite zone locale a été modifié...). Les Belges utilisent les subareas avec un outil qui se charge tout seul de reconstruire les frontières de niveau inférieur, lorsqu'une plus petite zone de niveau supérieure est modifiée: pas d'incohérence (sauf temporairement: le robot fait le travail bien mieux qu'un humain, sans erreur). Ils l'utilisent aussi pour faciliter l'import de données externes (depuis des bases de données qui n'ont strictement AUCUNE définition géolocalisée permettant la recherche des sous-zones). Cette automatisation des remontées de frontières automatisées est justement possible dès qu'une zone est entièrement partitionnée en zones filles. S'il manque des tracés, ce n'est pas du tout un problème: la zone est marquée comme non encore partitionnée ou contient des FIXME pour les zones manquantes (que strictement rien n'empêche de créer immédiatement même sans encore aucune frontière définie, afin de permettre justement des imports externes des données géolocalisées qui manquent: on crée la zone sans frontières, ou avec une frontière incomplète pas encore fermée, on la référence avec un subarea, et on avance...). Ceux qui travaillent sur le dessin d'un niveau (et ont un accès direct à des bases OpenData ou qui aiment dessiner des frontières précises verront ces manques de frontières suffisantes (qui sont signalés par nos outils). Notez que la définition des hiérarchique des subareas est
Re: [OSM-talk-fr] http://cadastre.cleo-carto.org n° des départements
Le 26 janvier 2012 22:27, Philippe Pary phili...@cleo-carto.com a écrit : Le 17/01/2012 00:58, sly (sylvain letuffe) a écrit : Sur http://cadastre.cleo-carto.org serait il possible de rajouter le n° du département en plus de son nom dans le premier menu déroulant ? Ça serait utile pour les nuls comme moi en géographie ;-) Pour les départements, c'est fait. Je les ai mis à la fin par contre, tu aurais peut-être préféré au début ? Je trouve ça plus joli à la fin, mais c'est moins pratique. Mais c'est plus joli. Mais c'est moins pratique. Bref, n'hésite pas à me dire ce que tu en penses. Le numéro INSEE pour les communes dans le second menu déroulant serait aussi un plus Là, sauf erreur de ma part, je ne peux y arriver uniquement avec les données cadastres. Je peux m'en sortir en recoupant avec d'autres données, mais pour ce soir j'ai la flemme de le faire :-) Juste une question concernant ce serveur: c'est normal qu'on ne trouve pas toutes les communes ? N'a-t-on que celles dont le cadastre a été vectorisé ? Parce que des communes manquent en Mayenne, et faut de mieux j'ai du insérer un contour très grossier (par exemple la limite nord de Vimarcé) tracé à la main, à vue de nez (en me basant sur un croquis montrant la forme générale de la commune, afin de compléter les frontières manquantes hors de celles des communes déjà vectorisées au sud dans l'arrondissement de Laval et la frontière vectorisée de la Sarthe). J'ai mis un FIXME sur cette commune (ainsi que dans l'arrondissement de Mayenne dont la frontière sud avec l'Arrondissement de Laval nécessite la frontière nord de Vimarcé (voire des autres communes limitrophes si le tracé grossier actuel n'est pas suffisant). Mais peut-être qu'on doit encore utiliser une image scannée (non vectorisée) du cadastre de ces communes manquantes, si votre serveur n'a pas de données vectorielles exportables en format OSM. Comment vous gérez ces frontières manquantes pour les 21% et quelques des communes françaises qui manquent encore dans OSM (pas même un croquis grossier, parfois même pas un nœud positionné pour leur centre) ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : http://cadastre.cleo-carto.org n° des départements
De : Philippe Verdy verd...@wanadoo.fr Juste une question concernant ce serveur: c'est normal qu'on ne trouve pas toutes les communes ? N'a-t-on que celles dont le cadastre a été vectorisé ? Oui l outil d extraction ne fonctionne qu avec les communes vectorisees Parce que des communes manquent en Mayenne, et faut de mieux j'ai du insérer un contour très grossier (par exemple la limite nord de Vimarcé) tracé à la main, à vue de nez (en me basant sur un croquis montrant la forme générale de la commune, afin de compléter les frontières manquantes hors de celles des communes déjà vectorisées au sud dans l'arrondissement de Laval et la frontière vectorisée de la Sarthe). J'ai mis un FIXME sur cette commune (ainsi que dans l'arrondissement de Mayenne dont la frontière sud avec l'Arrondissement de Laval nécessite la frontière nord de Vimarcé (voire des autres communes limitrophes si le tracé grossier actuel n'est pas suffisant). Mais peut-être qu'on doit encore utiliser une image scannée (non vectorisée) du cadastre de ces communes manquantes, si votre serveur n'a pas de données vectorielles exportables en format OSM. C est exactement ça, on utilise le plugin cadastre de JOSM en utilisant les feuilles au format raster. Dans le meilleur des cas elles contionnent deja des infos de gerefencement, sinon on georeference a l aide des croisillons si il y en a, sinon georeferencement a la mano a partir de reperes geodesiques par exemple. ( plus de details par ici http://wiki.openstreetmap.org/wiki/FR:JOSM/Fr:Plugin/Cadastre-fr#Utilisation_pour_les_communes_au_format_image ) Comment vous gérez ces frontières manquantes pour les 21% et quelques des communes françaises qui manquent encore dans OSM (pas même un croquis grossier, parfois même pas un nœud positionné pour leur centre) ? Cf la reponse juste au dessus, avec le cadastre raster. C est long ça prend du temps mais ça permet d avoir un tracé relativement propre. Un certain nombre de departements dont toutes les communes ne sont pas vectorisées ont les limites administratives de communes completes grace a ça. Julien De : Philippe Verdy verd...@wanadoo.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Cc : sly (sylvain letuffe) sylv...@letuffe.org Envoyé le : Vendredi 27 janvier 2012 2h00 Objet : Re: [OSM-talk-fr] http://cadastre.cleo-carto.org n° des départements Le 26 janvier 2012 22:27, Philippe Pary phili...@cleo-carto.com a écrit : Le 17/01/2012 00:58, sly (sylvain letuffe) a écrit : Sur http://cadastre.cleo-carto.org serait il possible de rajouter le n° du département en plus de son nom dans le premier menu déroulant ? Ça serait utile pour les nuls comme moi en géographie ;-) Pour les départements, c'est fait. Je les ai mis à la fin par contre, tu aurais peut-être préféré au début ? Je trouve ça plus joli à la fin, mais c'est moins pratique. Mais c'est plus joli. Mais c'est moins pratique. Bref, n'hésite pas à me dire ce que tu en penses. Le numéro INSEE pour les communes dans le second menu déroulant serait aussi un plus Là, sauf erreur de ma part, je ne peux y arriver uniquement avec les données cadastres. Je peux m'en sortir en recoupant avec d'autres données, mais pour ce soir j'ai la flemme de le faire :-) Juste une question concernant ce serveur: c'est normal qu'on ne trouve pas toutes les communes ? N'a-t-on que celles dont le cadastre a été vectorisé ? Parce que des communes manquent en Mayenne, et faut de mieux j'ai du insérer un contour très grossier (par exemple la limite nord de Vimarcé) tracé à la main, à vue de nez (en me basant sur un croquis montrant la forme générale de la commune, afin de compléter les frontières manquantes hors de celles des communes déjà vectorisées au sud dans l'arrondissement de Laval et la frontière vectorisée de la Sarthe). J'ai mis un FIXME sur cette commune (ainsi que dans l'arrondissement de Mayenne dont la frontière sud avec l'Arrondissement de Laval nécessite la frontière nord de Vimarcé (voire des autres communes limitrophes si le tracé grossier actuel n'est pas suffisant). Mais peut-être qu'on doit encore utiliser une image scannée (non vectorisée) du cadastre de ces communes manquantes, si votre serveur n'a pas de données vectorielles exportables en format OSM. Comment vous gérez ces frontières manquantes pour les 21% et quelques des communes françaises qui manquent encore dans OSM (pas même un croquis grossier, parfois même pas un nœud positionné pour leur centre) ? ___ 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èle surface Modèle frontière : Bilan
Le 26 janvier 2012 14:30, Hélène PETIT h...@free.fr a écrit : Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Pour une commune dont la forme fait que son centroïde calculé tombe en dehors de ses frontières et le label par défaut semble indiquer le nom d'une autre commune. Regarde les boucles de la Seine dans le 92 pour comprendre... À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Non ! L'admin_level de la polyligne peut être de niveau inférieur au niveau 8 de la relation communale. Regarde donc les communes en frontière d'arrondissement, de département, de région ou de pays: les polylignes des contours sont de niveau différents. L'admin_level de la polyligne indique aussi au moteur de rendu des tuiles comment dessiner (quel style de ligne, quelle épaisseur, quelle couleur) sur ce contour partiel. Un moteur de rendu de tuile ne charge pas nécessairement la totalité de la commune ou des communes environnantes, ni toutes les relations de niveau inférieur qui contiennent cette polyligne. Il se contente de regarder l'admin_level qu'on lui a assigné localement, et ça suffit car il ne voudra pas charger tous les noeuds et toutes les polylignes de la relation parente qui sortent de son rectangle de tracé, cela prendrait trop de temps et trop de données. Il demande au serveur les objets contenus dans un rectangle et le serveur ne lui retourne que les noeuds dans ce rectangle, les polylignes qui ont une intersection dans ce rectangle. En fait parfois il en oublie si la polyligne n'a pour seule interection qu'un seule segment de droite entre deux noeuds qui ne sont pas dans le rectangle d'intérêt, ce qui parfois aboutit à des morceaux oubliés de lignes dessinées d'une tuile à l'autre; pour régler cela, si plus tard une autre tuile est analysée contenant un noeud dont un trait sort du cadre, il marque les tuiles extérieures comme étant à revisiter plus tard en tenant compte de nœuds trouvés dans une autre tuile; de ce fait il peut aussi oublier des relations contenant des polylignes avec ces segments oubliés; je pense, sans l'affirmer, que cela marche avec des listes d'attentes marquant chaque tuile à redessiner avec les numéros de tuiles voisines contenant des noeuds de la base ou des noeuds calculés sur des rendus de lignes épaisses, mais dont les données ont été mises à jour et sont à charger depuis la base OSM en plus de celles des noeuds tombant dans la tuile à redessiner, afin d'avoir des données suffisantes pour ne rien oublier). En conséquence, les tuiles se mettent à jour avec des décalages dans le temps, en plusieurs passes successives selon la longueur des files d'attentes de tuiles à redessiner. Mais on doit encore lui mâcher le travail trait par trait, pour minimiser le nombre de ces oublis. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Le 27 janvier 2012 02:34, Philippe Verdy verd...@wanadoo.fr a écrit : Le 26 janvier 2012 14:30, Hélène PETIT h...@free.fr a écrit : Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Pour une commune dont la forme fait que son centroïde calculé tombe en dehors de ses frontières et le label par défaut semble indiquer le nom d'une autre commune. Regarde les boucles de la Seine dans le 92 pour comprendre... Si on ne tague que la relation avec son nom, comme la relation n'a pas de position bien définie pour le label, celui-ci sera par défaut positionné sur le centroïde. La relation contient en général un admin_center pour positionner son centre administratif (en principe à la Mairie). Mais des communes ont des contours tels que la mairie est très excentrée; bien que ce contour soit fortement convexe, le centroïde marche bien en général pour le positionner, mais il peut y avoir une position plus adaptée pour positionner le label sans recouvrir d'autres éléments importants. Le nom présent dans la relation peut aussi ne désigner qu'une partie de la commune pour celles qui sont éclatées en plusieurs exclaves, chacune pouvant avoir un nom distinct qu'il est plus adéquat d'afficher sur la carte en tant que lieu. La relation donne le nom de la commune elle-même, pas celui de ses parties. Hors seule une de ses parties contient un centre administratif (la mairie), l'autre partie se retrouverait sans noeud membre admin_center. Il faut alors positionner un label même sans admin_center pour nommer cette partie de façon visible sur la carte. Cependant ces parties définies dans des relations séparées ne sont en principe pas ce qui définit la relation de niveau 8, et pas forcément non plus un niveau 9 (arrondissement communal) ou supérieur (quartiers, pôle de proximité). Pourtant il y a bien une frontière admnistrative définie par cette relation à laquelle on souhaite donner un nom distinctif sur la carte (en général un toponyme géographique plus qu'un lieu place).. On a donc à régler ce genre de détails localement selon l'importance qu'on donne à ces noms. Par défaut une relation communale sera affichée avec le nom de la relation affiché le long de ses bordures tracées, ou sinon positionné sur le centroïde. Si la résolution est suffisante pour afficher un label à l'intérieur, le moteur cherchera à utiliser la position de l'admin_center (cependant pas son nom car le nom pourrait être celui du centre adminitratif tel que Hôtel de Ville, qui n'est pas suffisant pour nommer la commune sur la carte. Il reste alors le label pour aussi donner le nom à afficher sur la carte (qui lui apparait dans sa forme normale sans qualificatif de désambiguation, car certaines relations éloignées les unes des autres sont distinguées en ayant des noms qualifiés, facilitant les recherches par nom... On ne voudrait pas voir par exemple Paris (Texas) sur la carte du Texas, même si sa relation s'appelle ainsi, on préfère avoir juste Paris. Le rôle label est alors utilisé à la fois pour positionner le label à afficher sur la carte, et ce qu'il faut afficher. Si un label est présent, il est préférable au nom et la position d'un admin_center, et si ce dernier n'est pas présent non plus, par défaut on utilise sur la carte dessinée le nom de la relation positionné sur le centroïde de la relation. C'est comme ça que je vois les choses. Note: l'IGN utilise des centroïdes modifiés : en général il est positionné à la position du centroïde calculée, mais si cette position tombe hors de toute zone habitée de la zone, il le modifie en la position de la mairie sur l'entrée de son bâtiment principal. Parfois il le mettra sur la place centrale (Place de la Mairie, Place de l'Hôtel de Ville, dans les communes où la Mairie consiste en un ensemble de bâtiments administratifs sans qu'on puisse déterminer réellement lequel de ces bâtiments est le principal. si la mairie officielle est en fait construite dans un hameau séparé de l'agglomération principale (ça arrive dans les communes rurales), il peut garder la position de l'ancienne mairie
[OSM-talk-fr] Informations Holux GPS sport 260 pro
Bonjour, Je vois aujourd'hui une promotion (qoqa.fr) intéressante pour un gps. Est-ce que quelqu'un a des informations vis à vis de ce produit ? La page : http://wiki.openstreetmap.org/wiki/GPS_Reviews ne donne pas de grandes informations... Merci, Fabien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Informations Holux GPS sport 260 pro
Bonjour, Le manuel utilisateur disponible sur le site constructeur indique que la puce GPS est une Mediatek MTK3329 Il en est pas mal question sur les sites de drônes, du fait de son faible coût et de sa capacité à renvoyer 5 positions par seconde (contre 1 pour une puce classique SirF III). http://www.diydrones.com/forum/categories/705844:Category:61230/listForCategory Ceci étant, rien ne dit que le programme du GPS Holux permettra ce genre de bidouille (l'intervalle mini est annoncé à 1 sec. en page 99) Il y a une petite contradiction entre les 4 MB de mémoire et la capacité de 160 000 points. Cette dernière laisserait plutôt penser que c'est 64 MB. Dans ce cas, ça laisse de quoi voir venir. Le manuel indique qu'il faut utiliser le logiciel maison pour décharger les traces. Est-il possible de se passer de celui-ci (le boitier est-il reconnu comme une clef USB) ? Pour le reste, il a l'air d'avoir plein de fonctions sympathiques, et un écran monochrome qui ne doit pas consommer grand chose tout en restant bien lisible. Le 27 janvier 2012 08:29, Fabien marbolan...@gmail.com a écrit : Bonjour, Je vois aujourd'hui une promotion (qoqa.fr) intéressante pour un gps. Est-ce que quelqu'un a des informations vis à vis de ce produit ? La page : http://wiki.openstreetmap.org/wiki/GPS_Reviews ne donne pas de grandes informations... Merci, Fabien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
