J'ai jeté un coup d'oeil sur cette zone par simple curiosité et le travail sur les innombrables bras de ces fleuves et toutes ces iles me parait colossal, bravo ! J'ai tout de même une remarque, il m'a semblé que par endroit le waterway=river (le "linéaire") etait beaucoup plus grossièrement défini que les "riverbank" et qu'il apparait a des endroits non couvert par un riverbank alors qu'il pourrait être placé dans l'axe du bras principal du fleuve.
Vlad. On 16 nov. 2012, at 12:07, Colin Durand <colindur...@hotmail.com> wrote: > Le long du Maroni ou de l'Oyapock je ne suis pas sur que nous fassions > beaucoup d'erreur en qualifiant tous les sites d'illégaux :-( mais ce n'est > peut être pas à nous de le faire...Dans le doute je pensais les qualifier en > carrière en dessinant un polygone autour de leur extension. Moi en gros, > utilisateur coldurand, je remonte le fleuve et suis vers Grand Santi. Pareil > si tu vois de grosses erreurs n'hésites pas à me le signaler, je ne suis pas > un expert d'open street map. > > Pour les villages, tous pourraient être repérés à partir des orthos bing. > ensuite il faudrait que je me rapproche de mon ancien employeur en Guyane > pour avoir une autorisation d'utiliser les données. Toi du coup, pour > t'intéresser à ce coin tu connais la Guyane ? > > a + > > Colin > > > > > From: talk-fr-requ...@openstreetmap.org > > Subject: Lot Talk-fr, Vol 76, Parution 110 > > To: talk-fr@openstreetmap.org > > Date: Thu, 15 Nov 2012 20:19:36 +0000 > > > > Envoyez vos messages pour la liste Talk-fr à > > talk-fr@openstreetmap.org > > > > Pour vous (dés)abonner par le web, consultez > > http://lists.openstreetmap.org/listinfo/talk-fr > > > > ou, par email, envoyez un message avec 'help' dans le corps ou dans le > > sujet à > > talk-fr-requ...@openstreetmap.org > > > > Vous pouvez contacter l'administrateur de la liste à l'adresse > > talk-fr-ow...@openstreetmap.org > > > > Si vous répondez, n'oubliez pas de changer l'objet du message afin > > qu'il soit plus spécifique que "Re: Contenu du digest de Talk-fr..." > > > > > > Thèmes du jour : > > > > 1. Re: Cartographie Fleuve Maroni Oyapoque Guyane (Stéphane MARTIN) > > 2. Re: Quelles fonctionnalités techniques vous manquent ? Mode > > d'édition polygone (Philippe Verdy) > > 3. Re: Quelles fonctionnalités techniques vous manquent ? Mode > > d'édition polygone (Balaitous) > > 4. Re: Landuse Multipolygon et rendu Mapnik (Jérome Armau) > > 5. Re: Quelles fonctionnalités techniques vous manquent ? Mode > > d'édition polygone (Philippe Verdy) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Thu, 15 Nov 2012 14:46:15 -0300 > > From: Stéphane MARTIN <st3ph.mar...@laposte.net> > > To: talk-fr@openstreetmap.org > > Subject: Re: [OSM-talk-fr] Cartographie Fleuve Maroni Oyapoque Guyane > > Message-ID: <50a52a67.3060...@laposte.net> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > 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 ? > > > > @+ > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Thu, 15 Nov 2012 18:51:14 +0100 > > From: Philippe Verdy <verd...@wanadoo.fr> > > To: Discussions sur OSM en français <talk-fr@openstreetmap.org> > > Subject: Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous > > manquent ? Mode d'édition polygone > > Message-ID: > > <caga7jc3btxssippvt4dnbp+9j5wjzhsyrb3wrtzpx1x0g6y...@mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > 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 > > > > > > > > -------------- section suivante -------------- > > Une pièce jointe HTML a été nettoyée... > > URL: > > <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121115/bc4d3049/attachment-0001.html> > > > > ------------------------------ > > > > Message: 3 > > Date: Thu, 15 Nov 2012 19:05:35 +0100 > > From: Balaitous <balait...@mailoo.org> > > To: Discussions sur OSM en français <talk-fr@openstreetmap.org> > > Subject: Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous > > manquent ? Mode d'édition polygone > > Message-ID: <1353002735.10036.31.camel@balaitous> > > Content-Type: text/plain; charset="UTF-8" > > > > 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 > > > > > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Thu, 15 Nov 2012 10:54:50 -0800 > > From: Jérome Armau <jerar...@gmail.com> > > To: Discussions sur OSM en français <talk-fr@openstreetmap.org> > > Subject: Re: [OSM-talk-fr] Landuse Multipolygon et rendu Mapnik > > Message-ID: > > <CAM45rtGEobCrBYGnZTXi6E3ndejuX=orxb5ocecrz5ashcm...@mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > 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 > > > > > > > > -------------- section suivante -------------- > > Une pièce jointe HTML a été nettoyée... > > URL: > > <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121115/e53a8afd/attachment-0001.html> > > > > ------------------------------ > > > > Message: 5 > > Date: Thu, 15 Nov 2012 21:19:05 +0100 > > From: Philippe Verdy <verd...@wanadoo.fr> > > To: balait...@mailoo.org, Discussions sur OSM en français > > <talk-fr@openstreetmap.org> > > Subject: Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous > > manquent ? Mode d'édition polygone > > Message-ID: > > <CAGa7JC2_j5k7aX7Tg0fb9Z2Eew7MQ+8ab++=zrk3pu33q_y...@mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > 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 > > > > > -------------- section suivante -------------- > > Une pièce jointe HTML a été nettoyée... > > URL: > > <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121115/e19979a0/attachment.html> > > > > ------------------------------ > > > > _______________________________________________ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-fr > > > > > > Fin de Lot Talk-fr, Vol 76, Parution 110 > > **************************************** > _______________________________________________ > 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
