Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Philippe, tu devrais prendre un carnet de 10 tickets enhancement sur http://josm.openstreetmap.de/newticket ! Certaines idées me semble intéressantes, mais noyées dans un long mail sur une mailing list francophone elles n'ont aucune chance d'être implémentées :( ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Landuse Multipolygon et rendu Mapnik
2012/11/14 Lapinos03 lapino...@free.fr: Parfois, vaut mieux voir cela directement avec l'auteur. Une chance que je passais par là ! ;) Effectivement, le polygone inner de la relation intersectait le polygone outer, ce qui doit perturber Mapnik. Du coup, je l'ai sorti de la relation pour l'instant. Dans un polygone, les trous (role inner) ne doivent pas sortir des limites extérieures (role outer) dudit polygone. Si c'est le cas, il faut exclure la surface imbriquée de la relation et redéfinir les contours extérieurs du polygone pour qu'il n'y ait pas de chevauchement entre polygones. Là où il peut y avoir différentes interprétations sur la validité d'un polygone (et donc matière à contester le fonctionnement de osm2pgsql/mapnik), c'est lorsque le contour du inner touche le bord extérieur sans le franchir (pas d'intersection). Sly a lancé plusieurs discussions dans le forum des développeurs sur ce sujet pour faire émerger un consensus entre les différents outils OSM et les normes SIG. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent le plus en tant que contributeur OSM ?
Le 23/10/2012 20:14, sly (sylvain letuffe) a écrit : Mais il vous manque toujours quelques trucs pour que ça soit encore mieux ? Alors j'ai lancé un projet de test visant à constituer une liste définissant les voeux de réalisation qui vous manque le plus : http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist Je suis navré mais c'est en anglais, ce qui n'empêche pas que je peux tenter de recueillir ici vos avis, mais comme il y a aussi une logique de vote et qu'il est bon de savoir quels voeux existent déjà je ne promets rien et ça peut ne pas être super simple de gérer la passerelle. Ce serait bien de pouvoir faire une sélection non rectangulaire, style lasso dans les outils de dessin. Pratique pour (dés)intégrer le bâti ;-) -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent le plus en tant que contributeur OSM ?
Euh... si ton JOSM n'est pas trop vieux ça existe déjà (mais pas très pratique comme c'est implémenté)... Le 15 novembre 2012 11:29, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 23/10/2012 20:14, sly (sylvain letuffe) a écrit : Mais il vous manque toujours quelques trucs pour que ça soit encore mieux ? Alors j'ai lancé un projet de test visant à constituer une liste définissant les voeux de réalisation qui vous manque le plus : http://wiki.openstreetmap.org/**wiki/Contributors_** functionalities_wishlisthttp://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist Je suis navré mais c'est en anglais, ce qui n'empêche pas que je peux tenter de recueillir ici vos avis, mais comme il y a aussi une logique de vote et qu'il est bon de savoir quels voeux existent déjà je ne promets rien et ça peut ne pas être super simple de gérer la passerelle. Ce serait bien de pouvoir faire une sélection non rectangulaire, style lasso dans les outils de dessin. Pratique pour (dés)intégrer le bâti ;-) -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- 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] Quelles fonctionnalités techniques vous manquent le plus en tant que contributeur OSM ?
Le 15/11/2012 11:29, Jean-Francois Nifenecker a écrit : Ce serait bien de pouvoir faire une sélection non rectangulaire, style lasso dans les outils de dessin. Pratique pour (dés)intégrer le bâti ;-) Comme l'outil lasso de JOSM ? ;-) Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent le plus en tant que contributeur OSM ?
Le 23/10/2012 20:14, sly (sylvain letuffe) a écrit : Mais il vous manque toujours quelques trucs pour que ça soit encore mieux ? Alors j'ai lancé un projet de test visant à constituer une liste définissant les voeux de réalisation qui vous manque le plus : http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist Je suis navré mais c'est en anglais, ce qui n'empêche pas que je peux tenter de recueillir ici vos avis, mais comme il y a aussi une logique de vote et qu'il est bon de savoir quels voeux existent déjà je ne promets rien et ça peut ne pas être super simple de gérer la passerelle. Réparer OSM History Viewer, qui ne fonctionne plus depuis quelque temps, et qui était très pratique pour visualiser un changeset. Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Langue des toponymes des points frontaliers
Bonjour, Je viens de voir qu'un contributeur a remplacé le tag name par le tag name:fr sur ce point : http://www.openstreetmap.org/browse/node/271618415/history Le résultat est que le nom ne s'affiche plus sur le rendu Mapnik. Comme le point est situé sur la frontière, il peut paraître logique d'utiliser name:fr et name:it. Je sais qu'on ne doit pas tagguer pour le rendu, mais il me semble que le champ name doit être renseigné, selon le wiki. Quelle est la bonne façon de procéder ? Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
Je pense qu'il serait logique d'avoir les deux langues dans le name et une seule langue dans les name:xx Une carte générique afficherai les 2 noms, une carte dans une langue donnée n'afficherai que cette langue. Le 15 novembre 2012 12:16, Jean-Claude Repetto jrepe...@free.fr a écrit : Bonjour, Je viens de voir qu'un contributeur a remplacé le tag name par le tag name:fr sur ce point : http://www.openstreetmap.org/**browse/node/271618415/historyhttp://www.openstreetmap.org/browse/node/271618415/history Le résultat est que le nom ne s'affiche plus sur le rendu Mapnik. Comme le point est situé sur la frontière, il peut paraître logique d'utiliser name:fr et name:it. Je sais qu'on ne doit pas tagguer pour le rendu, mais il me semble que le champ name doit être renseigné, selon le wiki. Quelle est la bonne façon de procéder ? Jean-Claude __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- 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] Langue des toponymes des points frontaliers
2012/11/15 Jean-Claude Repetto jrepe...@free.fr: Quelle est la bonne façon de procéder ? D'après le wiki, on peut mettre les deux versions dans name séparés par un - http://wiki.openstreetmap.org/wiki/Multilingual_names Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
Le 15 nov. 2012 à 13:07, Pieren a écrit : 2012/11/15 Jean-Claude Repetto jrepe...@free.fr: Quelle est la bonne façon de procéder ? D'après le wiki, on peut mettre les deux versions dans name séparés par un - http://wiki.openstreetmap.org/wiki/Multilingual_names Ce serait donc adapté pour les noms des rues, dont les panneaux sont effectivement bilingues? Ce qui simplifierait, car on pourrait se dispenser de remplir les names:xxx dans les deux langues. Et la recherche fonctionnerait. Christian Rogel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
Je trouve dommage de se dispenser des name:xx=* en surplus du name=* car ils permettent de réaliser une carte dans une des langues disponibles et pas uniquement une carte multilingue (ou alors j'ai pas bien saisit le sens de ton message). La recherche Nominatim ne prends pas en compte les différents name:xx ? Le 15 novembre 2012 13:36, Christian Rogel christian.ro...@club-internet.fr a écrit : Ce serait donc adapté pour les noms des rues, dont les panneaux sont effectivement bilingues? Ce qui simplifierait, car on pourrait se dispenser de remplir les names:xxx dans les deux langues. Et la recherche fonctionnerait. -- 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] Langue des toponymes des points frontaliers
Quand on ne sait pas quelle langue utiliser dans un name cr les deux sont officielles, on indique les deux séparées par un - . Oui... mais: Dans certains cas il y a des exceptions dans les collectivités multilingues qui ont adopté une graphie officielle pour les deux langues (parfois on rencontre d'autres séparateurs, par exemple en Espagne dans les collectivités basques ou catalanes où on trouve un autre séparateur, comme le / ou aucun autre séparateur que l'espace ; il n'y a pas de règle alors pour ces séparateurs). Le nom officiel multilingue est à garder tel qu'il est dans name=*, en respectant le séparateur adopté et l'ordre (même si le nom est alors assez souvent abrégé dans chaque langue pour éviter certains éléments communs, et là je ne parle pas d'une abréviation comme St remplaçant Saint uniquement pour que ce soit moins long dans un champ limité alors que le nom complet non abrégé avec Saint est utilisé partout où on a la place ou poue éviter d'ajouter une homonymie). Mais cela n'exclue pas dans ce cas de mettre name:fr=* et name:it=* séparés afin de savoir lequel des noms est en français et lequel est en italien, pour le cas où on voudrait produire une carte monolingue, ou simplement pour pouvoir rechercher un libellé mentionné dans une seule langue et que c'est ce seul nom monolingue qui figure sur nombre de documents, ou parce que le contexte du document permet de savoir de quoi on parle parce que le nom complet multilingue a déjà été précisé. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
Attention : ne mettre plusieurs langues dans name=* que si ces langues ont le *même* statut officiel (par exemple le français et le néerlandais à Bruxelles). Entre un nom officiel et un nom dans une langue seulement reconnue régionalement qui ne désigne pas un nom légal, on met le nom officiel dans name=*, et les autres noms dans leur langue séparée. Et ceci même si on trouve par endroits des panneaux ne mentionnant qu'une des langues, pas toujours le nom officiel, ou pas toujours le même selon les endroits (de nombreux panneaux indicateurs vont utiliser des abréviations, même sur des parties non évidentes du nom complet, ou peuvent choisir d'alterner les langues selon le cas où la quantité d'autres informations à afficher sur le panneau ; dans mon coin, je trouve des panneaux indicateurs marqués Frontenay-R.R. et ce n'est pas évident de savoir ce qu'abrège ces deux R si on ne l'a pas entendu et lu avant, et il est tout aussi courant de trouver des panneaux abrégeant Saint- en St, et n'affichant que des lettres capitales : les panneaux sont faits pour être lisibles de loin et rapidement par un conducteur, pas pour afficher une graphie officielle comme sur un contrat, c'est un peu comme les noms d'usage par rapport aux noms offficiels). Nominatim se débrouillera pour trouver ces autres noms et afficher les noms trouvés clairement selon les priorités et les préférences de l'utilisateur. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
2012/11/15 Christian Rogel christian.ro...@club-internet.fr: Ce serait donc adapté pour les noms des rues, dont les panneaux sont effectivement bilingues? Ce qui simplifierait, car on pourrait se dispenser de remplir les names:xxx dans les deux langues. Et la recherche fonctionnerait. Non. Ca ne dispense pas d'utiliser les tags names:xxx. C'est en plus. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
Le jeudi 15 novembre 2012 à 13:36 +0100, Christian Rogel a écrit : Le 15 nov. 2012 à 13:07, Pieren a écrit : 2012/11/15 Jean-Claude Repetto jrepe...@free.fr: Quelle est la bonne façon de procéder ? D'après le wiki, on peut mettre les deux versions dans name séparés par un - http://wiki.openstreetmap.org/wiki/Multilingual_names Ce serait donc adapté pour les noms des rues, dont les panneaux sont effectivement bilingues? Je ne suis pas d'accord. Sur le territoire français, la langue officiel est le français ET UNIQUEMENT le français. Sur une frontière, les 2 langues séparées par un tiret est acceptable. Ce qui simplifierait, car on pourrait se dispenser de remplir les names:xxx dans les deux langues. Je ne suis pas d'accord. Il faut mettre les traductions alternatives dans les balises name:xx, cela permet de généré des cartes localisés. Exemple: Cartes en français, breton, Catalan, Basque et Occitan. http://tile.paulla.asso.fr/openlayers.html Et la recherche fonctionnerait. La recherche fonctionne déjà sur toutes les langues que ce soit une balise name ou name:xx Exemple http://nominatim.paulla.asso.fr/search.php?q=Shanghaiviewbox=-195.3% 2C82.68%2C195.3%2C-75.14 http://nominatim.paulla.asso.fr/search.php?q=centrale +fukushimaviewbox=-160.14%2C82.68%2C160.14%2C-75.14 http://nominatim.paulla.asso.fr/search.php?q=Parighjiviewbox=2.19% 2C48.95%2C2.51%2C48.76 Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] housenumber
Le message suivant de : ## Bonjour, Afin de numéroter les maisons le long d'une rue, je créais une relation type=associatedStreet name=du nom de la rue. Dans cette relation y était mis comme membres, la rue en rôle street et tous les bâtiments en house. Il fallait ensuite reprendre chaque building et ajouter addr:housenumber avec pour chacun, le bon numéro. Mais cette méthode est un peu laborieuse par sa répétition de devoir modifier chaque buildind. Essayant de trouver une méthode plus rapide, j'ai aussi essayé avec JOSM le [url=http://wiki.openstreetmap.org/wiki/JOSM/Plugins/AddrInterpolation]plugin AddrInterpolation[/url] (en cochant, Convertir un chemin en numéros de maison) qui permettait d'avoir une numérotation automatique tout en créant une relation avec la rue. Mais je n'arrive pas ici à ce les Noeuds addr:housenumber ainsi créé coïncident exactement avec l'emplacement des Noeuds du chemin créé pour l'occasion. Il faut à chaque fois déplacer ces Noeuds addr:housenumber pour les mettre à leur bonnes positions, alors que si ils correspondaint exactement aux Noeuds du chemin ils se trouveraient aux bons endroits. Existerait il pour ce pluqin une façon afin que les Noeuds se positionnent où l'on veut ? La modification dans ce plugin de la Présicion Actuel/Estimé/Potentiel, n'a pas donné de meilleurs résultats. Malheureusement, en parcourant la documentation, la méthode d'interpolation n'est pas trop conseillée lorsqu'il y a des buildings. Et ce ne devrait plus être des nœuds supplémentaires avec l'attribut addr:housenumber , mais le building lui même (ma première méthode) qui doit avoir cette valeur. Alors si vous aviez une méthode d'automatisation de numérotation adéquat, je suis preneur. Merci du partage de vos connaissances. a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
2012/11/15 Christophe Merlet red...@redfoxcenter.org: Je ne suis pas d'accord. Sur le territoire français, la langue officiel est le français ET UNIQUEMENT le français. Sur une frontière, les 2 langues séparées par un tiret est acceptable. Oui, la discussion portait bien sur ces cas-là, ceux dont les noms sont officiellement dans deux langues (cette montagne en OP dont le sommet fait frontière avec l'Italie. Ou le Rhin, par exemple, avec l'Allemagne). C'est vrai que autrement, les cas sont très rares en France (uniquement les toponymes, et peut-être quelques odonymes, frontaliers). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Placer 2000 points sur une carte
Le message suivant de : ## Bonjour, je m'interroge sur la démarche pour créer une carte régionale avec 2000 points. J'ai 2000 adresses administratives (10 rue de la pompe à paris par exemple) avec un poids donné. Je n'ai pas besoin que la carte soit dynamique, le plus simple est le mieux. En me basant sur cette réponse: http://forum.openstreetmap.fr/viewtopic.php?f=3t=283. J'envisage de faire 3 ou 4 catégories d’icônes suivant le poids, plus le point aura un grand poids plus son icone sera grande. Par contre, je me pose d'autres questions: Comment obtenir le fond correspond uniquement à la région correspondantes ou au moins avoir un détourage ? Comment faire pour obtenir des latitudes et des longitudes à partir des adresses ? Comment faire pour exporter la carte générée dans un fichier image statique ? Merci pour vos conseils. a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Maproulette pour la France ?
Bonjour, Les plus attentifs connaissent déjà l'application 'maproulette': http://lima.schaaltreinen.nl/remap/ qui pointe sur une erreur OSM choisie au hasard à chaque visite du site. Celui-ci ne concerne que les USA et pour l'instant, uniquement les problèmes de connectivité des highway. Je pense qu'un site similaire sur la France et basé sur des erreurs signalées par Osmose, par exemple, serait un moyen ludique de réduire certains types d'erreurs présentes en trop grand nombre dans OSM (genre un thème par mois avec les erreurs les plus nombreuses mais faciles à corriger, au niveau de l'éditeur et des solutions, pour que ce soit à la portée du plus grand public possible). D'après ce blog de l'auteur, il est en contact avec les gens de keepright ([1]). Mais je pense qu'on pourrait aussi en profiter ou développer une application similaire. Vous en pensez quoi ? Pieren [1] http://oegeo.wordpress.com/2012/10/29/new-maproulette-challenge-connectivity-bugs/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Maproulette pour la France ?
On Nov 15, 2012, at 3:37 PM, Pieren wrote: Les plus attentifs connaissent déjà l'application 'maproulette': http://lima.schaaltreinen.nl/remap/ […] Vous en pensez quoi ? Super outil et super idée ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Maproulette pour la France ?
Bonjour, Je viens de tester, et oui, cela peut aider à faire passer les longues soirées d'hiver :). Concept très sympathique. Mais je pense qu'il faut pouvoir changer de type d'erreur. Car là, au bout de quelques erreurs de connectivité corrigées, on va se lasser. Le même système qui prend une erreur au hasard depuis les contrôles osmoses, avec peut-être la possibilité de rester sur une certaine emprise, et on va cliquer du mulot ! Le 15 novembre 2012 15:42, Olivier Croquette m...@ocroquette.de a écrit : On Nov 15, 2012, at 3:37 PM, Pieren wrote: Les plus attentifs connaissent déjà l'application 'maproulette': http://lima.schaaltreinen.nl/remap/ […] Vous en pensez quoi ? Super outil et super idée ! ___ 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] Maproulette pour la France ?
Effectivement c'est très bien et ça permet d'organiser de façon ludique des sprint ou des soirées roulette :) 2012/11/15 Olivier Croquette m...@ocroquette.de: On Nov 15, 2012, at 3:37 PM, Pieren wrote: Les plus attentifs connaissent déjà l'application 'maproulette': http://lima.schaaltreinen.nl/remap/ […] Vous en pensez quoi ? Super outil et super idée ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Maproulette pour la France ?
C'est exactement la réflexion que je me suis faite hier soir. J'aime le côté serious game. Denis -Message d'origine- De : Pieren [mailto:pier...@gmail.com] Envoyé : jeudi 15 novembre 2012 15:38 À : Discussions sur OSM en français Objet : [OSM-talk-fr] Maproulette pour la France ? Bonjour, Les plus attentifs connaissent déjà l'application 'maproulette': http://lima.schaaltreinen.nl/remap/ qui pointe sur une erreur OSM choisie au hasard à chaque visite du site. Celui-ci ne concerne que les USA et pour l'instant, uniquement les problèmes de connectivité des highway. Je pense qu'un site similaire sur la France et basé sur des erreurs signalées par Osmose, par exemple, serait un moyen ludique de réduire certains types d'erreurs présentes en trop grand nombre dans OSM (genre un thème par mois avec les erreurs les plus nombreuses mais faciles à corriger, au niveau de l'éditeur et des solutions, pour que ce soit à la portée du plus grand public possible). D'après ce blog de l'auteur, il est en contact avec les gens de keepright ([1]). Mais je pense qu'on pourrait aussi en profiter ou développer une application similaire. Vous en pensez quoi ? Pieren [1] http://oegeo.wordpress.com/2012/10/29/new-maproulette-challenge- connectivity-bugs/ ___ 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 : Import de données créées dans ArchiCAD
Sebastien, En plus de Bing, l'agence géospatiale d'Afrique du sud (SANSA) offre de l'imagerie satellite de haute résolution. Dans JOSM, si je me localise à Soweto, cette imagerie est proposée, identifiée comme South Africa CD:NGI Aerial. Pierre De : sebastien.di...@free.fr sebastien.di...@free.fr À : Liste francophone OSM talk-fr@openstreetmap.org Envoyé le : Mercredi 14 novembre 2012 3h40 Objet : [OSM-talk-fr] Import de données créées dans ArchiCAD Bonjour, Hier soir, j'ai initié à (J)OSM un étudiant de l'école d'architecture de Toulouse qui va partir à la fin de la semaine en Afrique du sud avec 9 de ses camarades (qu'il formera lui-même à (J)OSM) dans le cadre d'un projet d'aménagement d'un quartier défavorisé de Soweto. Ces étudiants ont voulu travailler en amont en créant, à partir d'une photographie aérienne que je n'ai pas vue et dont il n'a pas su me donner l'origine, un plan du quartier dans ArchiCAD (http://www.graphisoft.com/products/archicad/). Et bien évidemment, ils voudraient désormais importer ces données préliminaires (qui seront actualisées et enrichies sur le terrain) dans OSM. Mais j'ai identifié deux problèmes : 1. L'outil travaille dans un repère métrique qui lui est propre et les données ne sont donc pas géoréférencées. 2. ArchiCAD ne propose que peu de formats d'export vectoriel. Celui dans lequel je fonde le plus d'espoirs est DWG (1). Mes questions sont donc les suivantes : 1. Connaissez-vous un outil qui, à partir de quelques points d'appui, saurait géoréférencer des données vectorielles et qui supporterait le format DWG ? 2. Savez-vous comment on peut importer dans JOSM des données géoréférencées au format DWG ? Je n'ai pas trouvé ce format dans la liste proposée en entrée. 3. S'il n'est pas possible d'importer des données au format DWG, connaissez-vous un outil de conversion du format DWG vers un format supporté par JOSM ? Je vous remercie par avance, Sébastien (1) * Non, je ne parle pas du Data Working Group mais du format de données natif d'AutoCAD. * Les autres formats proposés par ArchiCAD sont soit matriciels (TIFF par exemple), soit antédiluviens et très spécifiques -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Pierre - Mail transféré - De : Pierre Béland infosbelas-...@yahoo.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 14 novembre 2012 8h44 Objet : Re: [OSM-talk-fr] Import de données créées dans ArchiCAD ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Landuse Multipolygon et rendu Mapnik
Pour le cas où un contour interne touche un contour externe, il n'y a pas d'ambiguïté : il **faut** utiliser la représentation la plus convexe possible utilisant le plus grand nombre d'anneaux et qui ne les fusionne pas en un seul anneau à forte concavité (où un même nœud est visité plusieurs fois par le même anneau). Cela fait alors que chaque anneau ne visite chacun de ses nœuds qu'une seule fois (sauf le premier et le dernier nœud de l'anneau fermé qui sont nécessairement les mêmes et qui forme une seule visite complète en entrée et en sortie). Alors tout anneau enferme SOIT la totalité de la surface d'un autre, SOIT une surface nulle d'intersection avec l'autre, SOIT sa surface est totalement dans l'autre. Cela forme alors une relation d'ordre partiel (sur les surfaces sans les bordures), même si ces anneaux d'un même multipolygone peuvent se toucher (uniquement sur un nombre fini de points, donc sur une longueur totale nulle). Dans un même multipolygone toutefois, si deux anneaux ont un segment commun de longueur non nulle, c'est qu'un des segments doit être découpé sur les noeuds d'un autre segment, avant d'éliminer les paires de segments communs, afin de fusionner les deux anneaux en un seul sans ce segment commun. Tout cela est malgré tout entièrement automatisable (comme aussi le fait alors de savoir si un anneau et interne ou externe, un jour ou l'autre on pourra se passer même de devoir préciser les rôles inner et outer dès que les outils les calculeront systématiquement eux-mêmes pour informer l'utilisateur). Dans ce cas les rôles seront utilisés pour autre chose ! Et permettront d'avoir n'importe quelle intersection entre membres d'une relation, tant que ce sont des rôles différents ; sauf les rôles (vide), inner, outer, enclave et exclave qui seront alors tous vus comme totalement équivalents les 4 derniers étant dépréciés ou tous automatiquement remplaçables en inner ou outer (pour les multipolygones uniquement, qui sont nécessairement formés uniquement de d'anneaux fermés, mais pas pour les multilinetrings dans lesquels les 2 rôles n'ont strictement aucun sens puisque les mutlinestring sont utilisés à la fois comme contours internes et externe selon les multipolygones qui les référence, même lorsque un multilinstring contient un ou plusieurs anneaux fermés). Le 15 novembre 2012 10:35, Pieren pier...@gmail.com a écrit : 2012/11/14 Lapinos03 lapino...@free.fr: Parfois, vaut mieux voir cela directement avec l'auteur. Une chance que je passais par là ! ;) Effectivement, le polygone inner de la relation intersectait le polygone outer, ce qui doit perturber Mapnik. Du coup, je l'ai sorti de la relation pour l'instant. Dans un polygone, les trous (role inner) ne doivent pas sortir des limites extérieures (role outer) dudit polygone. Si c'est le cas, il faut exclure la surface imbriquée de la relation et redéfinir les contours extérieurs du polygone pour qu'il n'y ait pas de chevauchement entre polygones. Là où il peut y avoir différentes interprétations sur la validité d'un polygone (et donc matière à contester le fonctionnement de osm2pgsql/mapnik), c'est lorsque le contour du inner touche le bord extérieur sans le franchir (pas d'intersection). Sly a lancé plusieurs discussions dans le forum des développeurs sur ce sujet pour faire émerger un consensus entre les différents outils OSM et les normes SIG. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Langue des toponymes des points frontaliers
C'est peut-être lus courant qu'on croit car plein de toponymes n'ont pas de statut officiel. Sinon il y a aussi les noms de sommets et cols de montagne. Et plein de noms d'établissements privés qui sont souvent l'association de plusieurs noms. Le nom officiel étant rarement visible ou connu (sauf sur les tickets de facturettes carte bancaire oùù c'est souvent le seul qui apparait) car nombre d'éablissment utilsient plutôt un nom d'enseigne ou plusieurs enseignes. On parlait il y a peu du nom des stades: les murs du stade et même bon nombre d'installations sont restés publics, même si un club de foot privé y est installé et affiche son nom privé qui peut être composé lui aussi de plusieurs enseignes : faut-il alors utiliser uniquement le nom donné par le club ou celui officiel (le club de foot n'y ayant pas tous les droits non plus, car il n'en qu'un des utilisateurs même si c'est celui qui paye le plus) ? Le 15 novembre 2012 14:49, Pieren pier...@gmail.com a écrit : 2012/11/15 Christophe Merlet red...@redfoxcenter.org: Je ne suis pas d'accord. Sur le territoire français, la langue officiel est le français ET UNIQUEMENT le français. Sur une frontière, les 2 langues séparées par un tiret est acceptable. Oui, la discussion portait bien sur ces cas-là, ceux dont les noms sont officiellement dans deux langues (cette montagne en OP dont le sommet fait frontière avec l'Italie. Ou le Rhin, par exemple, avec l'Allemagne). C'est vrai que autrement, les cas sont très rares en France (uniquement les toponymes, et peut-être quelques odonymes, frontaliers). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
J'ai déjà envoyé les tickets sur ce que je considère le plus sérieux. Certains problèmes sont simples à résoudre (avec peur de modifs à faire une fois qu'on a isolé et bien identifié la source du problème) mais pour d'autres les solutions se discutent et les tickets sont mal placés pour être discutés car il y a plus de choses à écrire. Un autre constructeur statique pour les boites d'alerte de JOSM construisant une interface plus utile que la bête alerte par défaut de Swing qui n'est pas faite pour afficher des messages de contenu dynamiques au contenu imprévisible, est un projet simple à concevoir, ça s'isole bien. La gestion des focus d'entrée entre les fenêtres de JOSM (surtout quand elles le perdent face à une autre application) est aussi simple à concevoir. C'est pourtant un problème quand on a plusieurs fenêtre ouvertes dans JOSM. Il peut être nécessaire aussi de discuter le comportement qu'on devrait avoir pour savoir comment repositionner un focus utile (ce n'est pas si évident que ça). Les raccourcis trop compliqués pour mettre à jour des données suffisantes (CTRL+ALT+U ou D), et un mode de travail qui limiter les conflits ou erreurs et oublis se conçoivent très bien (même si ce mode de travail sera un peu plus lent à cause des requêtes supplémentaire au serveur) mais là les solutions à apporter se discutent avant. Le 15 novembre 2012 09:56, Christian Quest cqu...@openstreetmap.fr a écrit : Philippe, tu devrais prendre un carnet de 10 tickets enhancement sur http://josm.openstreetmap.de/newticket ! Certaines idées me semble intéressantes, mais noyées dans un long mail sur une mailing list francophone elles n'ont aucune chance d'être implémentées :( ___ 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] Import Bâti communes de Haute-Saône
bonjour cela fait quelques jours que j'ai entrepris l'import systématique du bâti disponible pour les communes rurales de Haute-Saône je tiens à jour l'avancée du travail sur la page : http://wiki.openstreetmap.org/wiki/Communes_de_la_Haute-Sa%C3%B4ne Est ce que les plus experts d'entre nous peuvent regarder si je n'incorpore pas trop d'anomalies. Je m'efforce de corriger les routes, les noms de voies d'après le cadastre. (au moins pour quelques une), l'occupation du sol, etc ? est-ce qu'il faut systématiquement corriger les alertes bâtiment à l'intérieur d'un autre ? j'aurais peut-être du poser la question plus tôt ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Cartographie Fleuve Maroni Oyapoque Guyane
Bonjour, Je viens de m'inscrire sur cette liste après avoir vu que certaines personnes cartographiaient la frontière Guyane / Brésil le long du fleuve Oyapoque. J'étais en train de faire la même chose de l'autre coté sur la frontière Suriname / Guyane, le long du fleuve Maroni après avoir bossé là bas il y a quelques temps déjà. Je cartographie principalement les iles et bras du Fleuve. Pour ce qui est de la frontière je ne m'amuse pas à la déplacer en sachant que la frontière sur cette zone n'est pas bien définie, il est par exemple impossible de savoir si certaines îles sont françaises ou surinamaise. Pour ce qui est du nom de tous les villages / hameau le long de ce fleuve nous en avions fait une carte exhaustive pour une bonne partie du fleuve Maroni mais largement basée sur les orthophotographies de l'ign je ne peux donc pas l'utiliser directement car basée sur des données non libres. Il faudrait que je réfléchisse à faire en sorte de l'utiliser dans la règles, dans ce cas la Open Street Map deviendrait sans problème la carte la plus précise sur la zone, la dernière de l'IGN doit dater des années 60 sauf si elle a été reprise récemment. Pour la précision des images, les images bing sont celles de l'IGN qui si elles ne sont pas trop modifiées c'est ce qu'il y a de plus précis pour la guyane Et, une petite interrogation, ceux qui travaillent sur ces zones, savez vous comment caractériser les camps d'orpaillage ? Bonne soirée, Colin. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie Fleuve Maroni Oyapoque Guyane
Salut, Le 15/11/2012 14:22, Colin Durand a écrit : Bonjour, Je viens de m'inscrire sur cette liste après avoir vu que certaines personnes cartographiaient la frontière Guyane / Brésil le long du fleuve Oyapoque. J'étais en train de faire la même chose de l'autre coté sur la frontière Suriname / Guyane, le long du fleuve Maroni après avoir bossé là bas il y a quelques temps déjà. Je cartographie principalement les iles et bras du Fleuve. Pour ce qui est de la frontière je ne m'amuse pas à la déplacer en sachant que la frontière sur cette zone n'est pas bien définie, il est par exemple impossible de savoir si certaines îles sont françaises ou surinamaise. Pour ce qui est du nom de tous les villages / hameau le long de ce fleuve nous en avions fait une carte exhaustive pour une bonne partie du fleuve Maroni mais largement basée sur les orthophotographies de l'ign je ne peux donc pas l'utiliser directement car basée sur des données non libres. Il faudrait que je réfléchisse à faire en sorte de l'utiliser dans la règles, dans ce cas la Open Street Map deviendrait sans problème la carte la plus précise sur la zone, la dernière de l'IGN doit dater des années 60 sauf si elle a été reprise récemment. Pour la précision des images, les images bing sont celles de l'IGN qui si elles ne sont pas trop modifiées c'est ce qu'il y a de plus précis pour la guyane Et, une petite interrogation, ceux qui travaillent sur ces zones, savez vous comment caractériser les camps d'orpaillage ? Bonne soirée, Colin. Bienvenue ;-) Vais me sentir moins seul ! Tu as dû constater que j'avais retaillé beaucoup les riverbanks des grands fleuves, dont le Maroni jusqu'à grosso modo Maripasoula (contributeur Stephixus). Si j'ai fait des conn, pas hésiter à me le dire ! Me suis attaqué à l'Oyapock et c'est loin d'être fini :-( Le tout à partir de Bing. Pas possible de replacer les villages du fleuve avec Bing ? Pas visibles ? Si tu as besoin d'un coup de main pour de la saisie... Quant aux sites d'orpaillage, tu parles des légaux ou des clandestins ? Il me semble que les légaux sont taggés comme des carrières. Sinon je n'ai jamais rentré dans OSM un site illégal. Je pense qu'il faudrait tagger pareil avec un attribut en plus, mais lequel ? Un truc du genre operator:illegal ? @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
En plus c'est bien ici qu'a été lancée cette discussion, non ? Les tickets c'est surtout pour ensuite ne pas oublier qu'on a des solutions possibles, et du travail maintenant à faire pour le suivi. Une discussion c'est forcément plus long, le ticket lui reste très résumé : soit il signale un problème sérieux (que l'auteur du ticket n'explique ou ne comprend pas) et on n'a pas de solution proposée, il faut quelqu'un d'autre pour analyser le problème. Mais pour les enhancements (améliorations proposées), le ticket n'est pas la première méthode de suivi, on peut en avoir des tas sans même aucune évaluation de ce que ça représente, et les propositions ne sont ps toujours non plus les plus simples pour un même problème de base, ou peuvent se faire de façon plus graduée (ça peut aussi vite être une fausse piste si on travaille dessus tout de suite et ça peut compliquer d'autres choses qui marchent bien déjà). L'amélioration proposée doit alors avoir plusieurs objectifs: peut-être faciliter le travail pour certains mais si pour les autres plus nombreux ça le complique, il vaut mieux ne pas les inclure mais les mettre dans un autre plugin optionnel (si ça intéresse d'autres personnes pour les créer), avec aussi le mérite de faire une expérimentation à part ente plusieurs solutions possibles. Le 15 novembre 2012 09:56, Christian Quest cqu...@openstreetmap.fr a écrit : Philippe, tu devrais prendre un carnet de 10 tickets enhancement sur http://josm.openstreetmap.de/newticket ! Certaines idées me semble intéressantes, mais noyées dans un long mail sur une mailing list francophone elles n'ont aucune chance d'être implémentées :( ___ 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] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Non, je pense qu'un tel outil est réalisable. La plupart des cas d'utilisations concernent des polygones simples, je pense en particulier au landuse. Plus de détail sur un début de spécification possible : Fusion de polygones : Condition d'utilisation : Sélection de 2 polygones avec au moins 1 point commun (simple pas des multipolygones) = Les polygones n'appartiennent à aucune relation : fusion avec éventuellement boite de dialogue pour gérer les tags en conflits = Les polygones appartiennent tous les deux à une même relation = Les polygones ont le même rôle : fusion, il n'en reste qu'un dans la relation = Les polygones ont des rôles différents : message d'erreur = Les polygones appartiennent à deux relations différentes : message d'erreur Scission d'un polygone : Condition d'utilisation : Sélection d'un polygone (simple) et d'un way dont les extrémités appartiennent au polygone et n'ayant aucun attribut (way créé dans le seul but de la scission) = Le polygone n'appartient à aucune relation : création de deux nouveaux polygones héritant des mêmes tags, et suppression du way = Les polygones font partie d'une relation : idem, et de plus les deux polygones créés font partie de la relation avec le même rôle. Je ne pense pas que cela puisse introduire des incohérences. En l'état actuel, je me refuse à modifier Corinne (même si j'ai fait quelques tentatives), alors qu'il y a beaucoup à faire de ce côté là. Si quelqu'un trouve ma proposition intéressante, ça serait bien qu'il la relais à un endroit adéquat. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Landuse Multipolygon et rendu Mapnik
Merci pour avoir corrigé ca. Dans le futur, est-ce qu'il serait possible / souhaitable d'incorporer cette vérification à l'analyseur de relations openstreetmap.fr? 2012/11/14 Lapinos03 lapino...@free.fr Parfois, vaut mieux voir cela directement avec l'auteur. Une chance que je passais par là ! ;) Effectivement, le polygone inner de la relation intersectait le polygone outer, ce qui doit perturber Mapnik. Du coup, je l'ai sorti de la relation pour l'instant. En regardant de près le rendu (avant qu'il ne soit régénéré maintenant), on distingue en filament vert le contour de la forêt (inner). Bizarre. A+ Le 14/11/12 20:05, Jérome Armau a écrit : Bonjour, J'ai un problème avec un multipolygon de landuse: http://www.openstreetmap.org/browse/relation/2547665 . Le polygone de forêt inner (http://www.openstreetmap.org/browse/way/154694507) n'est pas rendu correctement par mapnik, mais http://api.openstreetmap.fr/analyse/cgi-bin/index.py me dit que la relation est correcte - alors qu'on dirait que le inner dépasse des frontières du polygone extérieur, ce qui dérange probablement mapnik. Qui a tort dans ce cas ? Merci ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://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] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Tes conditions exposées sont encore trop simples, tu oublies de parler dans les polygones que tu fusionnes le fait qu'ils puissent être membres de relations différentes (et n'ont pas à être fusionnés même si tous les attributs sont identiques). La boite de résolution de conflits me semble pratiquement toujours indispensable pour informer l'utilisateur de ce qui va se passer dans les autres relations référentes dont les membres vont être modifiés). Et plus on essaye de combiner par une seule commande les opérations (qu'on fait actuellement en plusieurs étapes) en une seule, plus le nombre de cas de conflits à résoudre augmente et est compliqué à interpréter pour l'utilisateur dans la boite de résolution de conflits. Le résultat obtenu n'est alors plus du tout une simplification mais bien une complication qui va produire encore plus d'erreurs ou d'incompréhensions car le nombre d'objets (noeuds, chemins, relations, y compris les référents) distincts modifiés simultanément augmente avec pour chacun leurs propres attributs et rôles. Sinon on peut toujours augmenter le nombre de commandes différentes pour un certain nombre de cas particulier, mais là encore ça n'est pas simple non plus de comprendre et distinguer les plus nombreuses commandes disponibles et de leur donner un nom ou une description signifiante et assez précise pour les distinguer. Les opérations de fusion sont encore plus sensibles en terme de complexité que les opérations de scission (mais même une scission pose une difficulté selon la façon de les faire : intersections à calculer et effectuer, conservation de l'intersection ou d'une des deux différences possibles). Même si on départ la sélection n'est qu'un seul noeud, le fait qu'il puisse être membre de plusieurs relations ou chemins nécessite une désambiguation (comme actuellement déjà) de l'action à effectuer et il faut alors un second objet pour préciser un contexte. Mais alors comment interpréter la sélection de deux objets ? (un sur lequel effectuer l'action, l'autre pour préciser le contexte) : il faudrait des sélections asymétriques avec encore un critère à comprendre. Le 15 novembre 2012 19:05, Balaitous balait...@mailoo.org a écrit : Non, je pense qu'un tel outil est réalisable. La plupart des cas d'utilisations concernent des polygones simples, je pense en particulier au landuse. Plus de détail sur un début de spécification possible : Fusion de polygones : Condition d'utilisation : Sélection de 2 polygones avec au moins 1 point commun (simple pas des multipolygones) = Les polygones n'appartiennent à aucune relation : fusion avec éventuellement boite de dialogue pour gérer les tags en conflits = Les polygones appartiennent tous les deux à une même relation = Les polygones ont le même rôle : fusion, il n'en reste qu'un dans la relation = Les polygones ont des rôles différents : message d'erreur = Les polygones appartiennent à deux relations différentes : message d'erreur Scission d'un polygone : Condition d'utilisation : Sélection d'un polygone (simple) et d'un way dont les extrémités appartiennent au polygone et n'ayant aucun attribut (way créé dans le seul but de la scission) = Le polygone n'appartient à aucune relation : création de deux nouveaux polygones héritant des mêmes tags, et suppression du way = Les polygones font partie d'une relation : idem, et de plus les deux polygones créés font partie de la relation avec le même rôle. Je ne pense pas que cela puisse introduire des incohérences. En l'état actuel, je me refuse à modifier Corinne (même si j'ai fait quelques tentatives), alors qu'il y a beaucoup à faire de ce côté là. Si quelqu'un trouve ma proposition intéressante, ça serait bien qu'il la relais à un endroit adéquat. Balaitous ___ 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] Langue des toponymes des points frontaliers
Le 15 nov. 2012 à 14:31, Christophe Merlet a écrit : Je ne suis pas d'accord. Sur le territoire français, la langue officiel est le français ET UNIQUEMENT le français. Sur une frontière, les 2 langues séparées par un tiret est acceptable. Tu fais l'erreur habituelle : le français n'est pas et n'a jamais été la langue officielle des toponymes. Sauf, peut-être quand on a (ré)annexé l'Alsace-Lorraine ou annexé le nord des Alpes-maritimes en 1946. Au risque de me répéter : Il existe, à l'inverse, une version officielle des toponymes et celle-ci peut prendre des colorations linguistiques très diverses : - Français du 18è. Ex. Le Champ du Roy - Français du 19è/20è/21è Ne pas oublier que ces toponymes ont souvent des origines latines, germaniques, basques, celtiques, etc., masquées par l'évolution de la prononciation - Mi-français / mi langue locale : Rue de Penc'hoat , Carrière du Puech - Tout en langue locale : Hent ar C'hazh-Koad (= Chemin de l'Ecureuil) Dans le champ name, IL N'Y A PAS de référence au français, seulement le nom que l'on constate être employé par l'administration compétente. Les communes, qui ont le pouvoir de dénommer les voies et les lieux peuvent officialiser : - une version nouvelle qui peut être le retour à une ancienne appellation - une version nouvelle dans le champ linguistique local - un couple version officielle ancienne/version traduite ou adaptée nouvelle Dans ce cas, la première version est déclarée officielle et l'autre n'est qu'un complément La commune de Pluguffan, limitrophe de Quimper, a acté comme nom officiel le couple nom du champ linguistique français/nom du champ linguistique breton Personne ne sera étonné d'apprendre que les techniciens du SIG ne trouvent pas ça pratique, mais, c'est à eux de s'adapter. Rectification : Comme dit Christian, si on met un name en deux langues (point frontalier ou commune de Pluguffan), il faut, bien sûr, renseigner les names de champ linguistique. Christian Rogel___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Landuse Multipolygon - analyseur de relation
Le jeudi 15 novembre 2012 19:54:50, Jérome Armau a écrit : Dans le futur, est-ce qu'il serait possible / souhaitable d'incorporer cette vérification à l'analyseur de relations openstreetmap.fr? Souhaitable : oui possible : oui Est-ce que ça va être fait : non Plus personne ne s'occupe de cet outil, et il est juste maintenu en l'état. Toutefois, si quelqu'un se motive pour s'en occuper, la réponse deviendra oui. Connaissances requises : python+java -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Bâti communes de Haute-Saône
mon toc etant les erreurs osmose sur les batiments, j'ai regardé ta derniere intégration de batiments : Faymont effectivement il y avait 4 batiments avec des chevauchements, detectabele comme tu l'as précisé. ces chevauchements étaient a la marge ainsi que quelques batiments a fusionner http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents/Aper%C3%A7u_des_erreurs_rencontr%C3%A9es pour le reste, je n'ai rien vu de choquant, donc +1 pour toi Peut etre le tag source cadastre a enlever sur les etangs si tu les a repris avec bing. +1 pour le tableau de suivi pour les anomalies, il y a les outils dédiés http://osmose.openstreetmap.fr/map/?lat=47.60661lon=6.58806zoom=15 http://tools.geofabrik.de/osmi/?lat=47.60661lon=6.58806zoom=15 http://wiki.openstreetmap.org/wiki/FR:Outils_de_validation bonne contigration (continuation+intégration) didier Le jeudi 15 novembre 2012 à 18:14 +0100, Jean-François Gaffard a écrit : bonjour cela fait quelques jours que j'ai entrepris l'import systématique du bâti disponible pour les communes rurales de Haute-Saône je tiens à jour l'avancée du travail sur la page : http://wiki.openstreetmap.org/wiki/Communes_de_la_Haute-Sa%C3%B4ne Est ce que les plus experts d'entre nous peuvent regarder si je n'incorpore pas trop d'anomalies. Je m'efforce de corriger les routes, les noms de voies d'après le cadastre. (au moins pour quelques une), l'occupation du sol, etc ? est-ce qu'il faut systématiquement corriger les alertes bâtiment à l'intérieur d'un autre ? j'aurais peut-être du poser la question plus tôt ! ___ 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
