<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Etienne Trimaille a écrit :
<blockquote
cite="mid:AANLkTi=FX3-yaiVHuvQsEyEfxZnOoDE6zjqro13DL41D@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type"
content="text/html; charset=ISO-8859-1">
Oh, ca sent bon tout ça ! :)<br>
<br>
Concernant l'extraction de la largeur des voies d'eau, le script V le
permet déjà il me semble. Peut-être inutile de réinventer la roue ...</blockquote>
<br>
attention a l'import de l'eau a partir du script V, c'est un probleme
qu'on rencontre de plus en plus souvent<br>
<br>
sur le cadastre il y a des zones bleues qui signifient plus "ne pas
construire, zone inondable" que "voie d'eau"<br>
<br>
evidamment les voies d'eau y sont, mais aussi des petits ruisseaux ou
meme des chemins creux qui ne charrient de l'eau qu'en cas de fort orage<br>
<br>
de plus c'est sous forme de zones rarement jointives et sans la ligne
centrale qui est d'usage dans OSM<br>
les bords de ces zones sont en general les limites des parcelles
riveraines et non pas la berge de la voie d'eau, sur les gros fleuves
ca correspond pas trop mal mais sur les petites rivieres c'est assez
catastrophique<br>
<br>
j'appelle donc a ne pas envoyer toutes ces donnees dans la base brutes
de decoffrage comme c'est trop souvent le cas<br>
<br>
ce qui est assez fiable sur le cadastre : les grosses voies d'eau, les
lacs, etangs et mares, les piscines<br>
tout le reste doit etre importe avec prudence en verifiant que ca
existe reellement sur le terrain (aller voir, photos aeriennes, etc...)<br>
et pour tout ce qui est cours d'eau, meme les gros, il faut fusionner
les chemins qui viennent du script V et rajouter des bouts pour assurer
la continuite, et aussi rajouter le chemin central<br>
</body>
</html>