Re: [OSM-talk-fr] 2 relations pour le Rhône

[Jérôme Seigneuret]

Salut,

Les polygons sont tous englobé dans un multipolygon.  Vas savoir
pourquoi... C'est pour cela que tout les tag sont remontés au niveau de la
relation.

Pour le reste, il y a tous les éléments à inclure dans une relation
type=waterway inclus dans la relation sous la forme d'un main_stream,
d'un side_stream ou d'autre type... dont waterbody ou riverbank (area)

J'ai l'impression que la relation englobante est le mutipolygone et ça n'a
pas de sens... les élément de type natural=water
doivent être inclus dans la relation type=waterway et la relation de type
mulipolygon sur tous les éléments natural=water est inutile. Il y a lieu
d'avoir du multipolygone seulement s'il y a des iles

Dans tous les cas l'emprise des zones d'eau n'est pas incluse dans la
première relation et c'est pas normal donc à voir
http://wiki.openstreetmap.org/wiki/Relation:waterway

Jérôme



Le 14 décembre 2015 à 14:21, Tony Emery  a écrit :

> Bonjour à tous,
>
> Je ne sais pas si vous l'avez remarqué, mais le fleuve Rhône possède 2
> relations 660056 et 1075117.
>
> Si j'ai bien compris, la relation  660056
>    concerne
> l'emprise surfacique du fleuve alors que la relation  1075117
>    concerne le
> filaire.
>
> Comprenez-vous la même chose que moi et si c'est la cas, pourquoi cette
> bizarrerie ?
> De plus, le objets de la relation des emprises n'ont (presque tous) plus
> aucun tag, ce qui fait qu'on ne peut plus les récupérer dans les requêtes
> simples (waterway=* ou natural=water).
>
> Avez-vous le même problème ? Est-ce une erreur ?
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/2-relations-pour-le-Rhone-tp5862437.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Tony Emery]

Jérôme Seigneuret wrote
> Dans tous les cas l'emprise des zones d'eau n'est pas incluse dans la
> première relation et c'est pas normal donc à voir
> http://wiki.openstreetmap.org/wiki/Relation:waterway
> 
> Jérôme

Du coup, on peut corriger tout ça ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/2-relations-pour-le-Rhone-tp5862437p5862448.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 2 relations pour le Rhône

[JB]

Le 14/12/2015 20:43, Jérôme Seigneuret a écrit :

D'ailleurs en multipolygone sous JOSM c'est automatiquement fusionné

Pardon ? Tu peux préciser, s'il te plait ?
JB.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Jérôme Seigneuret]

Le 14 décembre 2015 à 20:49, JB  a écrit :

> Le 14/12/2015 20:43, Jérôme Seigneuret a écrit :
>
>> D'ailleurs en multipolygone sous JOSM c'est automatiquement fusionné
>>
> Pardon ? Tu peux préciser, s'il te plait ?
> JB.


Ok j'ai mal présenté la chose...

Soit  un way fermé A, un way fermé B et un way fermé C.
A et B sont jointifs et C et situé entre les deux et est jointif donc avec
A et B

Si tu combines A et B les entités sont transformés en une seul faisant
parti d'un mutipolygone avec le role outer et C est incluse avec le role
inner directement. Les attributs de A et B sont alors remonté sur la
relation multipolygone (avec alerte si des clés ou valeurs sont différentes)

Sinon A et B sont juste incluse dans le multipolygone ça émet une alerte
car il existe des parties jointives

Sinon sans multipolygone, rien n’empêche de mettre A et B dans un autre
type de relation. type=waterway s'apparente à un dictionnaire de données
dans lequel on regroupe des objets avec des role specifique

Sans C, A et B peuvent être fusionné et cela n'implique en aucun cas un
multipolygone.

Si le multipolygone n'apporte pas de précision spécifique c'est qu'il sert
à rien. C'est juste un groupement d'élément de même nature.
C'est comme mettre des landuse=residential sans nom dans une relation
multipolygone. Inutile
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Jérôme Seigneuret]

>
>
>
> Pour le lit, c'est un corps d'eau, et un multipolygone va très bien, qu'il
> y ai des iles ou non.
>
> Oui sauf que c'est inutile surtout pour des entités accolés... D'ailleurs
en multipolygone sous JOSM c'est automatiquement fusionné et dans le cas de
muti-area jointif ça renvois une alerte
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Frédéric Rodrigo]

Là les deux ont
type = waterway
water = river
Ce n'est pas possible.
Ça ce n'est que pour le tracé filaire.

Pour le lit, c'est un corps d'eau, et un multipolygone va très bien, 
qu'il y ai des iles ou non.


http://wiki.openstreetmap.org/wiki/Relation:waterway

Frédéric.


Le 14/12/2015 15:40, Tony Emery a écrit :

Jérôme Seigneuret wrote

Dans tous les cas l'emprise des zones d'eau n'est pas incluse dans la
première relation et c'est pas normal donc à voir
http://wiki.openstreetmap.org/wiki/Relation:waterway

Jérôme

Du coup, on peut corriger tout ça ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/2-relations-pour-le-Rhone-tp5862437p5862448.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Philippe Verdy]

Sauf que le multipolygone a justement des attributs, partagé par tous ses
membres qui n'en ont pas besoin, et qu'il n'utilise qu'un seul membre à
part dans la relation waterway. Il est d'autant plus utile qu'il n'est pas
complet (il manque en fait des tas de riverbanks ou certains éléments ne
sont pas jointifs aux autres).
Le wiki décrit même cette possibilité au lieu d'ccumuler plein de membres
dans la relation waterway, justement pour les longs fleuves qui ont trop de
membres: les riverbanks peuvent être stockés à part dans leur propre
relation...
Ce n'est pas redondant, ça allège même énormément pour les longs fleuves
(et le Rhône n'est pas le seul dans ce cas...).

Cet
e-mail a été envoyé depuis un ordinateur protégé par Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Le 14 décembre 2015 à 21:15, Jérôme Seigneuret  a
écrit :

>
> Le 14 décembre 2015 à 20:49, JB  a écrit :
>
>> Le 14/12/2015 20:43, Jérôme Seigneuret a écrit :
>>
>>> D'ailleurs en multipolygone sous JOSM c'est automatiquement fusionné
>>>
>> Pardon ? Tu peux préciser, s'il te plait ?
>> JB.
>
>
> Ok j'ai mal présenté la chose...
>
> Soit  un way fermé A, un way fermé B et un way fermé C.
> A et B sont jointifs et C et situé entre les deux et est jointif donc avec
> A et B
>
> Si tu combines A et B les entités sont transformés en une seul faisant
> parti d'un mutipolygone avec le role outer et C est incluse avec le role
> inner directement. Les attributs de A et B sont alors remonté sur la
> relation multipolygone (avec alerte si des clés ou valeurs sont différentes)
>
> Sinon A et B sont juste incluse dans le multipolygone ça émet une alerte
> car il existe des parties jointives
>
> Sinon sans multipolygone, rien n’empêche de mettre A et B dans un autre
> type de relation. type=waterway s'apparente à un dictionnaire de données
> dans lequel on regroupe des objets avec des role specifique
>
> Sans C, A et B peuvent être fusionné et cela n'implique en aucun cas un
> multipolygone.
>
> Si le multipolygone n'apporte pas de précision spécifique c'est qu'il sert
> à rien. C'est juste un groupement d'élément de même nature.
> C'est comme mettre des landuse=residential sans nom dans une relation
> multipolygone. Inutile
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr