[OSM-talk-fr] Cartographie Fleuve Maroni Oyapoque Guyane

Ven 16 Nov 13:58:28 UTC 2012

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 <colindurand at 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-request at openstreetmap.org
> > Subject: Lot Talk-fr, Vol 76, Parution 110
> > To: talk-fr at openstreetmap.org
> > Date: Thu, 15 Nov 2012 20:19:36 +0000
> > 
> > Envoyez vos messages pour la liste Talk-fr à
> > talk-fr at 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-request at openstreetmap.org
> > 
> > Vous pouvez contacter l'administrateur de la liste à l'adresse
> > talk-fr-owner at 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.martin at laposte.net>
> > To: talk-fr at openstreetmap.org
> > Subject: Re: [OSM-talk-fr] Cartographie Fleuve Maroni Oyapoque Guyane
> > Message-ID: <50A52A67.3060605 at 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 <verdy_p at wanadoo.fr>
> > To: Discussions sur OSM en français <talk-fr at openstreetmap.org>
> > Subject: Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous
> > manquent ? Mode d'édition polygone
> > Message-ID:
> > <CAGa7JC3BtXsSiPpvt4Dnbp+9j5wjZhSYrb3WRTZPX1X0G6Y0dQ at 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 <cquest at 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 at 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 <balaitous at mailoo.org>
> > To: Discussions sur OSM en français <talk-fr at openstreetmap.org>
> > Subject: Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous
> > manquent ? Mode d'édition polygone
> > Message-ID: <1353002735.10036.31.camel at 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 <jerarmau at gmail.com>
> > To: Discussions sur OSM en français <talk-fr at openstreetmap.org>
> > Subject: Re: [OSM-talk-fr] Landuse Multipolygon et rendu Mapnik
> > Message-ID:
> > <CAM45rtGEobCrBYGnZTXi6E3ndejuX=oRxb5OCecRZ5AsHcmqag at 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 <lapinos03 at 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 at openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
> > >
> > >
> > >
> > > _______________________________________________
> > > Talk-fr mailing list
> > > Talk-fr at 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 <verdy_p at wanadoo.fr>
> > To: balaitous at mailoo.org, Discussions sur OSM en français
> > <talk-fr at openstreetmap.org>
> > Subject: Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous
> > manquent ? Mode d'édition polygone
> > Message-ID:
> > <CAGa7JC2_j5k7aX7Tg0fb9Z2Eew7MQ+8ab++=zRK3PU33Q_yQGQ at 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 <balaitous at 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 at 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 at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> > 
> > 
> > Fin de Lot Talk-fr, Vol 76, Parution 110
> > ****************************************
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at 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/20121116/357546a0/attachment.htm>