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

[Philippe Verdy]

Le 28 janvier 2012 21:58, simon <msreau at gmail.com> a écrit :
> Le samedi 28 janvier 2012 21:26:40, Philippe Verdy a écrit :
>> Le 28 janvier 2012 08:41, Vincent de Chateau-Thierry
>>
>> <vdct at laposte.net> a écrit :
>> > Donc tracer à grandes lignes droites des limites de commune, comme pour
>> > la v1 de ce way :
>> > http://www.openstreetmap.org/browse/way/147478990
>> > ne rime pas à grand chose tant on casse le niveau de détail. Ça revient à
>> > faire manuellement un tracé du même niveau que le GeoFLA...
>>
>> Dire que ça "casse" le niveau de détail est un peu fort ! Entre zéro
>> détails et une ligne à peu près au 1/100 000, il y a une marge énorme.
>>
>> Tu noteras que je n'ai pas mis ça sans le signaler : les tags FIXME
>> sont très repérables (même par les outils automatiques actuels de
>> suivi en ligne qui les signalent et par JOSM aussi), le commentaire
>> aussi pour ceux qui consultent l'historique. Il n'y a rien de cassé.
>>
>
> Oui il n'y a rien de casser mais nous essayons de faire un effort collectif et
> d'aller tous dans le même sens. C'est le but du consensus trouvé dans le fil
> cité précédemment.
>
>> > Si tu veux contribuer côté tracés de limites communales, autant prendre
>> > le sujet par le bon bout, en commençant par prendre connaissance du
>> > fonctionnement de l'outil qui est coeur du sujet :
>> > http://wiki.openstreetmap.org/wiki/FR:JOSM/Fr:Plugin/Cadastre-fr
>>
>> Grosses anomalies de cet outil, ou alors je n'ai pas encore réussi à
>> m'en servir. Ca me plante tout et JOSM ne parvient même pas à
>> récupérer... Sinon de gros problèmes aussi pour avoir les images
>> Cadastre (le serveur d'imagerie retourne des tas d'erreurs, ou des
>> images tronquées). Le second ennui est aussi qu'il faut relancer JOSM
>> avec les nouvelles préférences.
>>
>> Ca m'énerve un peu que les tuiles d'images raster ne soient pas
>> automatiquement converties en Mercator. L'IGN fournit pourtant un
>> outil pour corriger les géométries, et documente comment ça marche.
>> Mais comme aussi le plugin sait faire aussi des corrections
>> géométriques (rotations et trnaslations uniquement) il ne pourrait pas
>> pousser un peu pour faire les déformations aussi ?
>>
>
> Ce plu-gin est un outil libre, libre à toi de faire la correction, rapporter
> les bugs au concepteur, payer quelqu'un pour corriger les bugs... et ou
> implémenter de nouvelles fonctionnalités.

Je suggère qu'il gère non seulement les transformations linéaires 2D
(rotation, translation, homothétie), mais aussi d'ajouter une 3e
dimension pour travailler en coordonnées homogènes: dans ce cas il
gère aussi les perspectives et déformations de longueurs liées à la
latitude, et au lieu de caler seulement deux croisillons, on peut en
caler 3, voire 4.

Toutes les plans cadastraux étant dans une projection conforme
(respect des angles), comme aussi la projection WGS84, cela marche
avec une transformation linéaire avec uniquement cette 3e dimension.

L'effet de perspective sera, lui, utile à l'imagerie aérienne en basse
altitude (images à 45 degrés) qui commence à s'imposer pour voir les
reliefs, hauteurs de bâtiments... Google Earth l'utilise (pas encore
Google Maps ou Bing qui travaillent uniquement sur l'imagerie en haute
altitude, ou sur une imagerie déjà corrigée partiellement des effets
de perspective, sur des zones ayant peu de relief).

Le RGF93 comprend non seulement une projection conforme (compatible
avec les systèmes européens et internationaux), mais aussi une version
3D sans projection (pour les données les plus précises qui prennent en
compte l'altitude).

La version suivante dur RGF93 devrait prendre en compte la direction
effective de pesanteur, afin de corriger les aberrations liées au
choix arbitraire du géoïde terrestre (différence angulaire entre la
normale du géoïde et la verticale réelle), ce qui sera utile aux
géomètres pour les constructions d'ouvrages d'arts et hauts bâtiments,
car ça permet des précisions réellement centimétriques : le calage des
données avec le modèle actuel se faisant alors en les ramenant en
coordonnées cartésiennes 3D (plus de géoïde, ni de projection 2D
conforme)

Le modèle 3D (cartésien) respecte à la fois les angles, les distances
et les surfaces, avec la précision qu'on veut et indépendamment de
l'échelle, mais évidemment il augmente le nombre de données
nécessaires par point, et les cartes du cadastre (ou de l'IGN) ne
peuvent que rester en 2D (mais peuvent mentionner les altitudes
exactes et les courbes de niveaux, ou bien concernant le cadastre
référencer cette direction effective de la verticale moyenne au centre
de carte, ou mieux de la verticale aux quatre coins avec les
croisillons, ce qui permettrait enfin de coller de façon plus exacte
les cartes des différentes zones cadastrales: fini les 4 ou 9 zones
Lambert qu'on doit connaitre et sélectionner au préalable, et fini
aussi le déplacement manuel, "à vue de nez", des croisillons des
cartes pour les superposer, on superpose à la place les points
géodésiques d'altitude et de direction verticale connue, ou alors on
entre les altitudes des croisillons).

Cependant OSM ne gère pas l'altitude dans sa base (on a bien un tag
"ele" mais il est très parcellaire et pas du tout utilisé pour les
rendus de cartes, sans parfois avec une indication affichée en texte,
telle une métadonnée), et on n'a pas d'outils pour la prendre en
compte de façon homogène. Dans l'immédiat, on peut tout de même
utiliser les coordonnées homogènes pour convertir directement
l'imagerie en WGS84 (et oublier les projections Lambert).