[OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe

Sam 10 Nov 00:33:15 UTC 2012

Le 9 novembre 2012 17:29, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> Le vendredi 09 novembre 2012 16:38:54, Philippe Verdy a écrit :
>> > - non vu que ça n'est qu'une région de la France
>>
>> En revanche les frontières maritimes territoriales ne sont PAS des
>> lignes naturelles
>
> ha bon ?

Je parle bien des frontières en mer (par exemple celle des 12 miles) :
il n'y a rien pour les marquer naturellement.

Je maintiens donc ce que j'ai écrit.

>> , ces chemins devraient être tagués comme des
>> frontières internationales (admin_level=2) tout autour de la
>> Guadeloupe, car ce sont des frontières de la France
>
> On pourrait aussi ne pas les tagguer du tout, cette information étant portée
> par la relation.

Peut-être, mais quand la relation n'est pas chargée, on ne voit pas ce
qui la définit comme étant une ligne adminsitrative, on voit juste un
trait anonyme sans aucun attribut. Je pense quand même que chaque
trait devrait avoir un rôle défini caractérisant sa nature: ligne
naturelle ou construite ou virtuelle. Surtout si on ne voit rien sur
une photo.

>> Bref je redemande que les admin_level soient TOUS les chemins des
>> lignes de côtes (chemins de type natural=coastline) qui en elles mêmes
>> ne sont QUE des lignes naturelles physiques et pas des frontières.
>
> En général, au mieux, on "propose", ça permet d'éviter de croire que osm c'est
> toi. C'est juste une question de forme, mais ça à l'avantage d'ouvrir le
> dialogue et permettre aux lecteurs qui te lisent (encore) d'en déduire le
> statu d'une telle proposition.

Je ne fais pas que le proposer car c'est justifié : les lignes
naturelles de côtes ne sont pas les frontières administratives. Nulle
part en France. Même quand c'est un axe de route ou de rivière/fleuve,
on ne voit pas que ce sont des frontières. Les vraies frontières ont
une autre définition délimitée par soit un bornage (qu'il faut
chercher sur le terrain car impossible de le voir sur une orthophoto,
soit par les plans et relevés cadastraux, soit dans des textes légaux
et traités internationaux avec des coordonnées, parfois seulement
matérialiées (en mer) uniquement par le croisement de deux lignes de
repérages depuis des points très éloignés. Dans des cas assez rares on
trouvera des bouées ou balises flottantes ancrées ou des mats scellés
au fond (mais qui sont souvent abîmés et pas remplacés).

> Passé ce détail de forme tu "demandes" quoi exactement ?
> Je ne comprends pas ce que tu veux dire : "admin_level" c'est un tag, c'est
> pas un chemin.

Que les chemins (ways) de type natural=coastline ne portent peut-même
aucun attribut boundary=* ni admin_level=*.

> Ta phrase est-elle :
> "Tous les chemins portant un admin_level devraient tous être un chemin
> représentant la côte"

> J'imagine que non, sinon on est mal barrée car la côte n'arrive pas encore
> jusqu'en Savoie.
> A la devinette, j'imagine que tu proposes donc que tous les chemins portant
> natural=coastline ne soient pas porteur d'un tag admin_level ni boundary ?
>
> ça me va, et ça tombe bien, c'est indiqué ici :
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Les_limites_administratives_c.C3.B4ti.C3.A8res

C'est pourtant bien ce que j'ai écrit, je ne vois pas comment tu peux
l'interpréter autrement.

>> >> - la construction "pyramidale" est nouvelle pour les départements, doit
>> >> elle être conservée telle que, ou passer au mode "chemin" pour être en
>> >> cohérence avec les autres départements ?
>>
>> Ce sont des éléments utiles pour la construction. Si les chemins sont
>> complets, stables et vérifiés ils pourraient être vus comme des
>> doublons mais ils ne codent en fait pas la même chose: pour OSM il est
>> encore nécessaire, afin de représenter une surface, que les polygones
>> soient fermés soit dans un seul chemin, soit en groupant les chemins
>> dans une relation fermés.
>
> Je n'ai pas compris, on ne devait pas parler de la même chose.

Peut-être mais de toute façon ce n'est pas une erreur même si on ne
parle pas de la même chose.

>> C'est une frontière naturelle et géographique. On peut toujours
>> définir une relation (non administrative) permettant de fermer et
>> nommer le contenu de chaque partie.
>
> C'est ce que j'ai fais, comme précisé dans mon mail d'avant.
>
>> Pas forcément un problème, et pas urgent du tout, cela ne gène
>> absolument pas et n'est pas une erreur en tant que tel (je pense même
>> que c'est à étendre à toute la France opur solidifier le modèle, le
>> stabiliser, et le rendre plus facile à maintenir, comme cela a été
>> fait dans les autres pays).
>
> Le débat ayant déjà eu lieu (et avec toi d'ailleurs) je propose de maintenir
> pour l'instant le statu quo en ce qui concerne tous les admin_level>2
> Pour des raisons de manque d'outils le gérant et de cohérence avec l'existant.

Pffff... parce que vous pensez que ça ne sert à rien alors qu'on passe
un temps considérable à essayer de réparer les trous. Dans les pays où
les deux modèles sont utilisés simultanément, il y a beaucoup moins
d'erreurs de frontières, elles sont beaucoup plus stables, et on a
toute la facilité de le contruire dans un sens ou dans l'autre. Les
deux représentations ne sont pas incompatibles entre elles (et ne
codent en fait pas la même chose) : une est géométrique, l'autre
relationnelle. Disposer des liens relationnels permet de n'ouvlier
personne quand on touche à la géométrie, et évite aussi des tas de
créations de doublons, ou de trous dans un niveau et pas les autres
car on est assurer de les avoir toujours tous en même temps en cas de
scission ou de fusion de chemins.

Le nombre d'opérations manuelles à faire pour chercher les voisins est
considérablement réduit, et on travaille beaucoup plus vite, je peux
l'assurer (et les autres pays l'ont constaté aussi).

Cela n'empêche pas de valider ce qu'on veut valider pour la France :
la géométrie par chemins. Et cela n'empêche pas pour autant de d'avoir
une définition relationelle (qui n'est PAS une relation de surfaces
comme vous le croyez encore puisque les surfaces ne sont définies QUE
par la géométrie, et QUE si celle-ci est complète, sans trous, et sans
doublons. La représentation des liens relationnels (parent/enfant)
consitute pourtant une quantité minime de données dans la base : 1
seule inclusion de membre par relation enfant. Ce qui n'est VRAIMENT
rien du tout à côté des dizaines ou centaines de membres qu'on met
pour inclure tous les chemins, en dupliquant ces inclusions à TOUS les
niveaux de frontières, et qui peut être construit extrêmement
rapidement tout en restant facilement vérifiable à partir de listes de
références.

>> Je viens de répondre à ce bémol, et entre place=island ou
>> natural=island, je ne sais lequel convient le mieux pour moi c'est
>> équivalent, on trouve l'un ou l'autre dans la base.
>
> Je vais rester sur place=island puisque le wiki ne parle pas de natural=island
> et je n'ai pas l'impression que c'est beaucoup utilisé le natural=island

Je pense aussi que place=island va mieux car sinon on a un conflit
entre natural=island et natural=coastline quand il s'agit d'un chemin
fermé pour une île en mer (pour les îles sur les cours d'eau ou lac on
n'a pas ce conflit car les cours lits de d'eau et lacs/étangs ne sont
pas définis par natural=* mais par des waterway=riverbank ; mais si le
chemin n'est pas fermé mais coupé en plusieurs morceaux autour de
l'île il faut une relation pour définir l'étendue d'eau, et dans ce
cas une relation où l'ile sera un membre "inner" pour lequel on ne
doit PAS mettre waterway=* sinon ça la noierait sous l'eau, ou bien il
faut découper l'étendue d'eau en plusieurs polygones adjacents autour
de l'île, ce qui n'est pas non plus idéal à cause des superpositions
de chemins : je préfère nettement la méthode définissant les étendues
d'eau douce avec une relation et dans ce cas là le waterway=riverbank
va dans la relation de l'étendue d'eau et n'a encore une fois rien à
faire pour la ou les relations définissant les zones terrestres de
l'île comme les landuse=* et autre natural=forest ou natural=wetland).

Je suis convaincu après avoir analysé le problème que tous les
natural=island qui restent encore devraient être convertis en
place=island pour permettre de décrire leur contenu naturel lui-même.