Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
J'aimerais dire mapping comes first, genre, on se mets d'accord sur un truc simple, on fait une jolie démo et documentation et ensuite on défini un truc de dingue en incluant et sans détruire le truc simple. Ok, on fait comme ça. Yaka. En fait, je devais pas avoir bien cherché, en voulant créer ma page de proposition, j'ai simplement trouvé que type=waterway n'était pas du tout sorti du chapeau et était déjà là, simple et comme j'imaginais. Impec, je vais utiliser ça. (j'ai patché mon osm2pgsql pour qu'il ne l'ignore pas) Je comprends donc maintenant que le débat est sur la création d'une relation pour la rivière au sens très large contenant plein de trucs, et dans une logique compatibilité ascendante, je la verrais bien incluant les relations type=waterway type=multipolygon + waterway=river_bank comme membre. Ma méthode http://www.openstreetmap.org/browse/relation/156145 (...) J'essaie de faire du tout-en-un : | | - une corde o \ / - moi || Il me parait pertinent de créer une relation qui représente un objet : la rivière, ça, ça me plaît et dont les rôles signifient sous quel aspect elle est regardée. ça, ça me semble trop attendre des rôles. L'utilisation des données devra donc être aware de tous les rôles, ça pourquoi pas à la limite, sauf que dans les cas actuels le rôle est utilisé pour définir la structure géométrique (inner, outer, exclave, etc.) donc il deviendrait tentôt un regard tantôt un quelle forme. Imagines que tu as une île sur ta rivière, tu va devoir la tagguer inner, sauf qu'il te faut aussi indiquer qu'il s'agit de waterbank, sinon l'algo de reconstruction va devoir s'arracher les cheveux pour deviner s'il s'agit d'un morceau du lit central ou un morceau de berge (ou un pont taggué en mode surface qui enjambe la rivière) Plutôt que de multiplier les objets, un pour l'aspect cours d'eau (pour dépasser les 60 km), un pour l'aspect plan d'eau et pourquoi pas un associated_river Certes certes, mais ne divise-t-on pas pour mieux régner ? Je comprends l'avantage de ta méthode : le nom n'est qu'a un seul endroit, la ref aussi, et dans un monde parfait ce serait l'avenir (quand plein d'outil magique gérerons), mais entre temps ça me semble dur à utiliser et un tros gros saut. Donc l'idée de une relation type=river qui contient des relations formant les géométries aurait ma préférence. [1] Ton exemple pour résoudre le problème des confluents dans les multipolygones m'a convaincu : des ways constituant un multipolygone plan d'eau, certains ways étant, de plus, riverbank, c'est net. Marrant, moi je commence à douter ;-) [2] J'éviterai toutefois le type route Je connaissais pas type=waterway, ça me semble plus logique je vais prendre ça -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
Le 15 juil. 10 à 18:59, sly (sylvain letuffe) a écrit : Le consensus c'est alors : pas de multi ? chacun son truc ? ou : sly, tu nous fais chier ! ;-) Ma méthode (La Charente : http://www.openstreetmap.org/browse/relation/961832) c'est de mettre le way du lit principal dans une relation pour avoir le tracé global du fleuve. Ensuite si je dessine les riverbank et que je m'attaque maintenant aux seuils et écluses je ne les met pas dans la relation pour l'instant. Il me semble plus simple de ne laisser que l'essentiel : le lit principal du fleuve (waterway=river). Mais on pourrait imaginer d'y accoler pleins de choses (riverbank, lock, weir...) mais il faudra définir des rôles un peu cohérent avant. J'y ait réfléchit (un peu) récemment et je me demandais si il ne serait pas aussi intéressant (dans un deuxième temps) de créer une autre relation pour le Bassin du fleuve qui inclurait la relation des way du fleuve ainsi que celles des affluents, ce qui permettrait avec une relation de dessiner tout un bassin. je pense sur j'essayerai plus tard (faut déjà que je finisse le fleuve) et ensuite j'attaquerai les affluents principaux. PS : concernant ton soucis de représenter les grands fleuves, j'ai commencé a mettre à jour la page wiki du projet france avec la liste des fleuves (de plus de 100 km pour l'instant) avec ce que j'ai pu agrégé a ce jour : http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau#Grands_Fleuves_.28.3E_100_km.29 On y trouve quelques relations qui semble construite a peu près sur le même modèle (uniquement le waterway), même si certain (La Loire par exemple) ont quelques riverbank en rôle. Y'a la relation Rhône qui est un peu a part : seulement 2 petit riverbank c'est un peu léger... -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
On 15/07/2010 18:59, sly (sylvain letuffe) wrote: relation Sauf que ma méthode est loin d'être reconnue et bien utilisée et que visiblement ça se bat fort : http://wiki.openstreetmap.org/wiki/WikiProject_Rivers entre ceux qui voudraient une relation qui contienne le nombre de canard par km^2, les berges innondables, non innondables, le tracé de la rivière tel qu'il était en 10 BC (non je ne vise pas un certain VP), et qu'au final rien n'avance. Et bien, il y en a s'il devaient mapper une sardine, peuchère, elle boucherai le port de Marseille, con ! Sly tu ezzagère ! J'ai jamais parlé de canard carré. Bon, plus sérieux. Ça avance tout de même un peu, même si c'est disparate : sur le wiki, il n'y a qu'une personne pour s'opposer à la relation. J'aimerais dire mapping comes first, genre, on se mets d'accord sur un truc simple, on fait une jolie démo et documentation et ensuite on défini un truc de dingue en incluant et sans détruire le truc simple. Ok, on fait comme ça. Yaka. Re-sérieux : Oui, intéressant de faire une mise à plat, surtout si des données viennt à se libérer pour l'hydrologie. D'autant plus qu'avec le cadastre pdf, les ruisseaux et rivières pleuvent, si je puis dire : j'ai nettoyé des plans d'eau sur la Seine. == Les rivières surfaces == Un peu la même chose en fait, je sais que le multipolygon ne plaît pas à tous, qu'il est courant de tagguer en méthode puzzle et que oui, ça a des avantages, mais là j'ai un peu les boules car on a dégommé mon travail sur l'isère : http://www.openstreetmap.org/browse/relation/278498 Et mes échanges de mails avec un certain PA94 ... Le consensus c'est alors : pas de multi ? chacun son truc ? ou : sly, tu nous fais chier ! ;-) le 3/ je n'oserai même pas le penser. Mon opinion = Outre le coté indélicat de la façon de faire, Je suis convaincu que ta méthode multipolygone est, à terme, la plus juste, mais la plus fragile [1]. De plus elle n'est pas simple à gérer pendant la construction. Une fois le puzzle construit, c'est relativement simple de changer la méthode du multi puisque les ways sont déjà existants et regroupés dans une relation. Un peu de découpe dans les pièces du puzzle, un peu de tri dans l'interface JOSM et hop, on obtient un pur multipolygone multiligne. Ma méthode http://www.openstreetmap.org/browse/relation/156145 (Âmes sensibles s'abstenir : la rivière présentée prend sa source dans un massif montagneux appelé Jura, dont l'origine remonte à bien avant 10 BC, soit à une époque appelée jurassique. Il se peut que des esprits faibles soient heurtés) J'essaie de faire du tout-en-un : La relation (peu importe dans un premier temps[2] son type, son nom...) regroupe des waterways et waterbank. Il me parait pertinent de créer une relation qui représente un objet : la rivière, et dont les rôles signifient sous quel aspect elle est regardée. Plutôt que de multiplier les objets, un pour l'aspect cours d'eau (pour dépasser les 60 km), un pour l'aspect plan d'eau et pourquoi pas un associated_river (pourquoi associated ? Jamais compris. Street tout court, ça ne suffit pas ?) [1] Ton exemple pour résoudre le problème des confluents dans les multipolygones m'a convaincu : des ways constituant un multipolygone plan d'eau, certains ways étant, de plus, riverbank, c'est net. [2] J'éviterai toutefois le type route : des éléments font partie d'une relation route pour représenter la voie navigable. Le type route ne me parait pas tout à fait indiqué pour désigner le parcours de molécules d'eau. Mais c'est un second débat. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
Le 15 juil. 10 à 21:52, Vincent Pottier a écrit : La relation (peu importe dans un premier temps[2] son type, son nom...) regroupe des waterways et waterbank. Il me parait pertinent de créer une relation qui représente un objet : la rivière, et dont les rôles signifient sous quel aspect elle est regardée. Plutôt que de multiplier les objets, un pour l'aspect cours d'eau (pour dépasser les 60 km), un pour l'aspect plan d'eau et pourquoi pas un associated_river (pourquoi associated ? Jamais compris. Street tout court, ça ne suffit pas ?) Pourquoi utilises tu le rôle waterbank ? Il existe riverbank qui convient à priori, c'est en tout cas celui que je comptais utiliser pour les riverbank de la Charente. Je note que ces area (way fermé) sont bien indiqué comme waterway=riverbank... En tout cas une bien jolie rivière. -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
Le jeudi 15 juillet 2010 19:30:54, Pierre-Alain Dorange a écrit : Ma méthode (La Charente : http://www.openstreetmap.org/browse/relation/961832) c'est de mettre le way du lit principal dans une relation pour avoir le tracé global du fleuve. ça me semble bien fait et utilisable, je crois que en abscence de consensus internationnal je vais faire ça, comme dit ici : http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau Ensuite si je dessine les riverbank et que je m'attaque maintenant aux seuils et écluses je ne les met pas dans la relation pour l'instant. Il me semble plus simple de ne laisser que l'essentiel : le lit principal du fleuve (waterway=river). Mais on pourrait imaginer d'y accoler pleins de choses (riverbank, lock, weir...) mais il faudra définir des rôles un peu cohérent avant. Je pense qu'un fourre tout n'est pas souhaitable, il serait très difficile d'en extraire les éléments. Je vois plus la chose sous forme de relation de relation. (cf mail d'après) PS : concernant ton soucis de représenter les grands fleuves, j'ai commencé a mettre à jour la page wiki du projet france avec la liste des fleuves (de plus de 100 km pour l'instant) avec ce que j'ai pu agrégé a ce jour : http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau#Grands _Fleuves_.28.3E_100_km.29 Je suis informaticien moi ! Ma religion m'interdit de préparer un rendu en listant à la main les 30 rivières/fleuves à représenter. Les + de 100km je peux les déterminer automatiquement par calcul, je vais pas m'en priver. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
Le 15 juil. 10 à 23:22, sylvain letuffe a écrit : Je suis informaticien moi ! Ma religion m'interdit de préparer un rendu en listant à la main les 30 rivières/fleuves à représenter. Les + de 100km je peux les déterminer automatiquement par calcul, je vais pas m'en priver. Je suis aussi informaticien mais ça n'empêche pas d'utiliser des listes de références (wikipédia ou le wiki osm peuvent faire l'affaire). Surtout que là il n'y a rien qui distingue un fleuve d'une rivière à ce jour dans osm (river tout les 2)... Mais c'est sur que le calcul de la longueur d'une rivière à partir de sa relation est intéressant ;-) -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
Ayant pas mal fait d'ajout autour de l'Yonne, j'ai créé une relation comme indiqué et rajouté l'Yonne dans les rivières de plus de 100km (292km). Ce genre de liste permet de voir l'avancée du travail de cartographie. Le site du SANDRE indique les longueurs des différents cours d'eau, cela permet de comparer avec la longueur actuellement présente dans OSM. Je n'ai mis que les waterway=river dans la relation, une autre relation pourrait reprendre les riverbank. Par contre je rencontre un problème, l'Yonne et la Canal du Nivernais (qui relie la Loire à la Seine via l'Yonne) partagent de nombreuses sections. Il était d'ailleurs intégralement cartographié, avec les écluses et leurs fréquences VHF. J'ai aussi créé une relation pour ce canal vu qu'il n'y en avait pas. -- Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
Le jeudi 15 juillet 2010 21:52:27, Vincent Pottier a écrit : entre ceux qui voudraient une relation qui contienne le nombre de canard par km^2 Et bien, il y en a s'il devaient mapper une sardine, peuchère, elle boucherai le port de Marseille, con ! Sly tu ezzagère ! J'ai jamais parlé de canard carré. ça doit être parce que je comprends mal l'anglais, mais tu avouera que dans ton envolée lirique, si tu n'as pas mentionné les canards, tu n'es pas passé loin : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Rivers VP : Because a river is a complex with (...) * an area: made by areas, (...) where we can swim or not, fish or not (...) Because the world is rich and complex and openStreetMap is ambitious. Loin de moi à penser que ces choses n'ont pas raison de figurer dans une méga relation de la mort qui tue, mais je pense qu'il est aussi nécessaire de segmenter la chose pour la rendre utilisable. Pitié, pense à ceux qui écrivent des scripts en python, des requêtes longues comme le bras et des p...@$*#~ de styles mapnik. On ne taggue pas pour un outil précis pour faire plaisir à un développeur feignant, mais je pense qu'il faut que ça reste utilisable, s'il faut un programme à intelligence artificielle pour en venir à bout après 2 semaines de calcul, on rend la donné vraiment dure à exploiter. Bon, plus sérieux. Ça avance tout de même un peu, même si c'est disparate : sur le wiki, il n'y a qu'une personne pour s'opposer à la relation. Il est borné, tant pis pour lui, l'idée est bonne, je pense qu'il faut juste segmenter. défini un truc de dingue en incluant et sans détruire le truc simple. Ok, on fait comme ça. Yaka. Yaka... jvéfaire, je suis un habitué des propositions qui n'aboutissent jamais. Je vois un truc avec une relation de fou genre type=river qui contient les canards, les poissons, les écluses mais qui contient des éléments utilisables indépendament que sont : - la relation faite de ways qui forme la longue ligne de la source à l'embouchure (role=center_stream, type=waterway) - la relation faite de ways qui forme la surface haute de la rivière (role=max_water_bed, type=multipolygon+waterway=riverbank, constituant l'ensemble de la rivière et/ou les ensembles puzzle qui forme la rivière) - ... L'avantage est que les sous-relations seraient utilisable telle quelle sans fioritures, et je pourrais faire simplement mon rendu en utilisant juste les type=waterway, sans devoir deviner selon les 100 roles possibles passés et à venir, s'il s'agit d'un morceau de berge, de pont ou du lit principal. [2] J'éviterai toutefois le type route : des éléments font partie d'une relation route pour représenter la voie navigable. Le type route ne me parait pas tout à fait indiqué pour désigner le parcours de molécules d'eau. Mais c'est un second débat. Ma foi, va pour type=waterway, c'est juste que j'avais trouvé bien l'idée que type définisse simplement la forme totale attendue par la relation et permette ainsi des outils généraux pour traiter les erreurs. type=multipolygon - contour(s) fermé(s) type=linestring (oups, route) - ligne(s) brisée(s) -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !
Le 15 juil. 10 à 23:44, Christian Quest a écrit : Ayant pas mal fait d'ajout autour de l'Yonne, j'ai créé une relation comme indiqué et rajouté l'Yonne dans les rivières de plus de 100km (292km). Tu as bien fait, mais l'Yonne est une rivière la liste était les fleuves, mais y'a pas de raison puisque certaines rivières sont plus longues que certains fleuves... (je me comprend). Je change donc le titre et il faudrait ajouter ou il se jette dans ce cas. Ce genre de liste permet de voir l'avancée du travail de cartographie. Le site du SANDRE indique les longueurs des différents cours d'eau, cela permet de comparer avec la longueur actuellement présente dans OSM. Je n'ai mis que les waterway=river dans la relation, une autre relation pourrait reprendre les riverbank. Par contre je rencontre un problème, l'Yonne et la Canal du Nivernais (qui relie la Loire à la Seine via l'Yonne) partagent de nombreuses sections. Il était d'ailleurs intégralement cartographié, avec les écluses et leurs fréquences VHF. J'ai aussi créé une relation pour ce canal vu qu'il n'y en avait pas. Plus bas il y a une liste des canaux. -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
