Le 28 janvier 2012 21:58, simon <msr...@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 >> >> <v...@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). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr