[OSM-talk-fr] superposition de frontières ( Était : Ariège)

[Philippe Verdy]

Entièrement d'accord, sauf en ce qui concerne les limites
administratives et le cours central des rivières qui est aussi une
ligne virtuelle, à l'exception de ses rives. Il n'y a aucun intérêt à
tracer deux traits superposés pour ce cours central, mais c'est encore
pire si on les superpose !

Pour moi un cours central de rivière se pose en suivant les points des
rives et en utilisant Shift+B pour positionner un point central : avec
assez de points sur la rive on obtient un joli cours central qui
correspond assez bien au tracé des rives (moyennant certains
ajustements par exemple dans les rias, où les rives varient selon la
marée et laisse découvrir des zones humides, qu'on devrait pouvoir
tracer séparément afin d'affiner les rives, le reste étant un type de
landuse (landuse=wetland ? Il n'y a pas un autre meilleur type pour
ces zones marécageuses à découvert, et inondées par marée haute).

Pour le reste, une rivière, même son cours central ou ses rives, et
une frontière administrative, ne devrait partager aucun nœud ni aucun
chemin superposé.

Il n'y a que les lignes de côtes qu'on utilise arbitraitrairement
comme frontière administrative (alors que la définition des frontières
administratives dépend de plusieurs définitions internationales :
ligne de base, mer territoriale, ZEE, ou extension du plateau
continental, l'utilisation de la ligne de côte mouvante ne posant pas
trop de problème car elle se situe bien en deça des autres limites).


Le 12 avril 2012 14:17, Vincent de Chateau-Thierry <vdct at laposte.net> a écrit :
> Bonjour,
>
>> Message du 12/04/12 13:55
>> De : "sly (sylvain letuffe)"
>
>> A : "Discussions sur OSM en français"
>> Copie à :
>> Objet : Re: [OSM-talk-fr] superposition de frontières ( Était :  Ariège)
>>
>>
>> > Je ne sais pas si certains d'entre vous pratiquez déjà cette astuce
>> > (multipolygon), mais je trouve ça plus satisfaisant que ce que je faisais
>> > dernièrement (superposition) …
>>
>> +1 je n'utilise que ça ou presque.
>> J'ajoute que JOSM dispose d'un plugin appelé "multipoly-convert" qui permet de
>> transformer en un clic un way fermé classique en polygone "relation"
>> (en conservant le tag source sur le way, et en transférant les autres tags sur
>> la relation)
>>
>
> De mon côté, à l'exception des lignes de côte (natural=coastline), je trace toujours des
> ways distincts pour les limites (tag boundary=administrative), ce qui n'empêche pas
> d'utiliser tout ou partie des nodes existants sur des ways "physiques" : rues, cours
> d'eau. Ça correspond à la proposition #2 de ce paragraphe :
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_
> limites_administratives#Limites_administratives_utilisant_des_.C3.A9l.C3.A9ments_physique
> s
>
> Plusieurs raisons :
> - le principe énoncé ici :
> http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element même si on n'est pas,
> avec les limites administratives, en présence d'éléments visibles sur le terrain,
>
> - une relation administrative qui inclut des rues, des cours d'eau, est plus complexe à
> "lire", elle a bien plus de membres que nécessaire.
>
> - la maintenance d'une telle relation est plus lourde. Je n'ai pas fait de stats, mais
> il m'arrive souvent de réparer des limites communales, et dans le lot des erreurs
> rencontrées, une grande majorité consiste en des polygones devenus invalides suite à la
> modification d'un élément physique inclus dans la relation : on retrace un cours d'eau,
> on allonge une rue, et le polygone défini dans la relation administrative n'est plus
> une boucle fermée.
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
> Je crée ma boîte mail www.laposte.net
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr