[OSM-talk-fr] Re : http://cadastre.cleo-carto.org n° des départements

[Philippe Verdy]

Le 31 janvier 2012 07:14, Vincent de Chateau-Thierry
<vdct at laposte.net> a écrit :
> Bonjour,
>
> Le 31/01/2012 02:30, Philippe Verdy a écrit :
>>
>> Le 30 janvier 2012 09:26, Hélène PETIT<hpmt at free.fr>  a écrit :
>>>
>>> Le 29/01/2012 09:50, Marc Sibert a écrit :
>>
>>
>>>> il est
>>>> d'usage de ne rien mettre dans la base plutôt que des informations de
>>>> mauvaise qualité.
>>
>>
>> Pas si mauvaise que ça, pusique l'INSEE fait pareil. Considères-tu
>> l'INSEE comme une merde à virer ?
>>
>
> Non, l'INSEE n'a rien à voir là-dedans. L'INSEE utilise un fond de l'IGN (le
> GeoFLA) pour afficher le contenu de ses bases stats et le Code Officiel
> Géographique.

Par "faire", je disais que l'INSEE l'utilise ces données, et pour cet
usage cela lui suffit car il ne juge pas ces contours comme
"merdiques". Il en besoin de telles données, et je ne vois pas
pourquoi d'autres n'en auraient pas besoin aussi. OSM doit pouvoir
répondre à ces usages aussi.

>>> Dans le cas présent, si on commence à mettre des
>>>>
>>>> contours de communes de mauvaise qualité (qui plus est, vont servir via
>>>> un système de pyramide à définir les contours du pays, mdr !) on ne
>>>> saura plus ce qui est de bonne ou de mauvaise qualité et ce sur quoi il
>>>> faut repasser.
>>
>>
>> Oui il faudra repasser. Mais on peut s'épargner du travail et
>> l'organiser.
>
>
> S'épargner du travail, ça oui : à commencer par le travail de saisir 2 fois
> un contour; à continuer par celui de détecter quelles communes sont bancales
> du fait de cette saisie à la serpe (le FIXME, je n'y crois pas).
> Et s'organiser, c'est déjà le cas, avec la batterie d'outils de suivi
> (beta.letuffe), de conversion (cleo), et les chantiers comme celui de
> suppression de contours approximatifs de l'automne dernier.

Suppression ? On travaille chemin par chemin en améliorant la
précision. Et même avec le cadastre il faudra jongler avec les
feuilles des deux communes limitrophes (voire 3 ou 4 aux points
d'extrémités des chemins pour les rapprocher avec une opération
manuelle, chemin par chemin. Il n'y a aucune suppression à faire, et
quoi qu'on fasse il persistera ces chemins, même si leur précision a
été améliorée.

>> J'ai bien mis dans le commentaire que c'était schématique
>> et destiné à être replacé par un contour plus précis d'origine
>> cadastrale. Et même si on utilise le cadastre, il faudra revoir
>> régulièrement aussi les frontières (car les contours de communes
>> évoluent avec le temps, et l'INSEE liste ces changements : les
>> communes sont amenées régulièrement à s'échanger des parcelles,
>> fusionner, se scinder. La géodésie évolue, et les cartes actuelles en
>> bitmap seront aussi versctorisées certainement dans un meilleur
>> modèle.
>
>
> Le changement de format (raster => vecteur) n'est pas forcément synonyme de
> gain de qualité géométrique (hélas).

>> En attendant on fait quoi ? Rien selon ton raisonnnement...
>
>
> Tu n'a pas compris le raisonnement. On fait, mais pas n'importe comment : on
> utilise le cadastre, y compris raster. Le cadastre raster, ça se manipule :
> ça se géoréférence, planche après planche, pour ensuite reproduire à la main
> les contours de commune. Le plugin cadastre-fr est l'outil principalement
> utilisé pour ça (il y a aussi cadget). Si chez toi il ne fonctionne pas, tu
> peux décrire tes problèmes sur cette liste, talk-fr ça sert aussi à ça. Si
> tu ne veux pas te lancer dans l'usage des planches en raster, aucun souci.
> Mais dans ce cas, merci de ne pas tracer façon GeoFLA les communes qui
> manquent, d'autres s'en chargeront via le cadastre.

>> Elles sont correctes en ce qui concerne ce qui est déjà cartographié.
>
> Et non. Ce que tu disais hier sur CORINE :
> "les délimitations sont maintenant assez farfelues et très
> éloignées de la réalité"
> s'applique puissance 10 à tes propres tracés "FIXME". Un peu paradoxal, non
> ?

Pas du tout. les données CORINE gardent leur utilité pendant un bon
moment. Car le travail à faire manuellement reste énorme et on aurait
trop de trous dans la carte. Même parcellaires, on ne part pas de
rien, et c'est plus facile de travailler sur des zones dont des objets
sont déjà signalés et à ne pas oublier, même si on les améliore.

Sans les données CORINE, la carte de la France serait d'une blancheur
aveuglante, on n'aurait aucune idée de la topographie sauf en de rares
points. La carte blanche découragerait bon nombre de contributeurs de
se lancer dans le travail. C'est pareil avec les communes: si rien
n'est marqué, personne ne se lance à y inclure des détails.

C'est logique de commencer à tracer une carte à une résolution faible
pour l'améliorer ensuite niveau par niveau. Et c'est plus motivant
justement de ne pas partir de rien. Ceux qui veulent une précision
améliorée dans une zone le font. Cela ne remet pas en cause l'utilité
de la carte.

> Pour ce genre d'usage, tu n'as absolument pas besoin de ces tracés imprécis
> : autant consulter directement le GeoFLA (il est sous licence libre en
> plus), sans l'importer dans OSM : tu auras les voisinages entre communes
> directement.
>
>
>> Mais évidemment on peut toujours améliorer et affiner. OSM fonctionne
>> sur ce principe. Les tracés schématiques ne sont pas incorrects au
>> regard de leur précision suffisante pour que l'INSEE puisse publier
>> des cartes statistiques immédiatement, et de même d'autres
>> utilisateurs d'OSM qui n'ont pas NECESSAIREMENT besoin de la
>> résolution maximale (celle de l'état actuel du cadastre, jusqu'à sa
>> mise à jour) sur *toutes* les cartes.
>
>
> Si un utilisateur a besoin de contours du niveau GeoFLA, il y a le GeoFLA.
> Utiliser en l'état les contours de communes d'OSM pour faire des cartes
> stats France entière serait une hérésie, il y a bien trop de points.

Faux problème: même les serveurs de tuiles savent éliminer des
segments dont la longueur est inférieure au pixel de rendu.

Ça se fait de façon automatique en fixant un seuil de longueur ou
d'angle pour les points intermédiaires, et en ne gardant que les
points d'extrémité. Et si une surface délimitée par ces traits est
trop petite pour être représentable clairement, un mécanisme identique
(seuil de surface) peut aussi remplacer cette surface par un seul
point qui sera représenté autrement (un symbole, comme un disque ou
une étoile, centré sur ce point).

Des outils automatiques peuvent ainsi extraire d'OSM des contours et
points avec une résolution limitée. Cela ne remet pas en cause les
données de base qu'il n'est pas nécessaire de modifier.

C'est extrêmement facile à faire dans ce sens là, alors que dans
l'autre sens c'est totalement impossible: il manque des données de
base même si on n'a pas besoin des détails.

> On essaie dans OSM d'avoir un niveau de définition homogène autour du 1/10.000

Le 1/10 000, je ne sait pas ce que c'est : ça ne veut rien dire du
tout dans un format vectoriel. Pour être clair on veut savoir si la
résolution est kilométrique ou métrique. Le facteur d'échelle n'a rien
à voir là dedans (il n'a strictement aucune influence sur un format
vectoriel qui peut être zoomé à n'importe quelle échelle). Seule la
longueur minimale de détail (ou nombre de points par mètre) est
pertinente si on parle de résolution.

La définition aussi n'a rien à voir: elle dépend du dispositif de
rendu lors de l'échantillonnage en pixels, et dépend aussi du niveau
de zoom arbitraire dès qu'on a un format vectoriel). On ne trace pas
dans OSM une carte raster mais une carte vectorielle, donc il n'y a
aucun pixel et donc aucune résolution. NE confondons pas les termes.