Re: [OSM-talk-fr] Résolution décalage Cadastre DOM -TOM
Le mardi 04 août 2009 à 01:17 +0200, Pieren a écrit : > > Avec cette translation - en plus du changement d'ellipsoïde - > j'obtiens enfin les mêmes chiffres que le cadastre. > Je vais pouvoir proposer rapidement une nouvelle projection dans JOSM > et ceux qui voudront mapper la Guadeloupe (et ses 34 limites > communales) pourront s'y mettre ;-) ça tombe bien... j'ai corrigé il y a quelques jour un bug en Guadeloupe. J'ai coupé en deux les iles de la Petite-Terre pour faire apparaitre distinctement la Terre de Haut et la Terre de Bas (sans les tirets) Mais je n'avais pas les contours précis :( Je me suis aussi posé la question de la manière dont il fallait baliser ces iles. Les 2 iles ont chacune un nom. les 2 ensemble porte un nom "d'archipel" Elle font en plus parti de la commune La Désirade, qui est aussi une ile. Cela fait parti de la Guadeloupe qui est , si je ne me trompe pas à la fois DOM et ROM... Bref une cascade de relation avec énormément d'exclave. Librement, -- Christophe Merlet (RedFox) signature.asc Description: Ceci est une partie de message numériquement signée ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Résolution décalage Cadastre DOM -TOM
2009/5/5 RatZillaS : > Bonjour à tous je vous livre les résultats de mes investigations pour le > cadastre dans les DOM. J'ai fais des vérifications graphiques sous > Quantum Gis d'un fichier échantillons de points extrait du cadastre en > ligne. La bibliothèque libre proj4 (dispo chez nos amis de l'OsGeo) > permet de configurer les paramètres de projections. > Dans cette bibliothèque on retrouve 'cs2cs' qui permet de convertir des > coordonnées entre deux systèmes géodésiques différents. L'avantage c'est > que cet utilitaire peut être très finement configuré (Ellipsoïde de > référence, Système géodésique etc..). Géoconv semble utiliser par défaut > l'ellisoïde du WGS84. Or lorsque l'on regarde les paramètres de > projection pour les DOM (Gpe et Mqe) c'est l'ellisoïde de Hayford qui > est utilisé. (Je n'ai pas réussi à avoir exactement le système IGN, il y > a toujours des décalages) > > Mais ce n'est pas la seule explication au décalage des fichiers OSM de > l'outil de Fred > J'ai enfin compris le problème de décalage de projection pour la Guadeloupe. Comme l'avait signalé Eric Sibert, il faut opérer une translation et ce sont les chiffres de cette translation qui sont particuliers à Sainte-Anne qui étaient faux dans l'outil geoconv (notez que le cadastre utilise encore l'ancienne projection). J'ai enfin découvert les bons chiffres (ils sont bien cachés, en tout cas pour moi), sur l'aide en ligne de Circé (Guadeloupe : Transformation Sainte-Anne ð RRAF) : TX = -472,29 m TY = -5,63 m TZ = -304,12 m Avec cette translation - en plus du changement d'ellipsoïde - j'obtiens enfin les mêmes chiffres que le cadastre. Je vais pouvoir proposer rapidement une nouvelle projection dans JOSM et ceux qui voudront mapper la Guadeloupe (et ses 34 limites communales) pourront s'y mettre ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Résolution décalage Cadastre DOM -TOM
> Comment est-tu sûr que ça n'est pas la seule explication ? Il serait > assez facile de modifier geoconv pour qu'il change d'ellipsoide. > Est-ce que tu as deja essayé ? > cs2cs et geoconv se valent dans les transformations, les outils sont bons ! Puisque les transformations UTM20N->WGS84 et l'inverse WGS84->UTM20N sont correctes. Je ne sais pas changer l'ellipsoïde avec géoconv.En revanche le changer avec cs2cs n'a rien changé. Je suis toujours un peu décalé ~200m. Je continue donc d'investiguer et de tester jusqu'à ce qu'on trouve une solution propre. > Il serait dommage d'appliquer un décalage constant sans comprendre les > raisons. D'autres DOM utilisent l'UTM et il est probable que ces > constantes ne s'y appliquent pas. Bien sûr, comme je le disais dans mon précédent mail, chaque ile a sa projection propre.Mon calcul n'est valable que pour la Guadeloupe et ses dépendances.Donc il est impératif de traiter chaque territoire au cas par cas. Et de vérifier les résultats des outils de conversion par les points géodésiques dont on connait assurément les coordonnées dans tous les systèmes utiles. J'ai à ce sujet des collègues de l'IGN à Aix qui doivent me renseigner.Il n'y a pas beaucoup de personne en prise avec les problématiques géomatiques ultramarines donc c'est un peu difficile d'avoir des infos. Mais on progresse, j'arrive à avoir un calage parfait des limites communales depuis ce matin sur la Guadeloupe donc c'est encourageant. FôS ! _ Hotmail® has a new way to see what's up with your friends. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Résolution décalage Cadastre DOM -TOM
2009/5/5 RatZillaS : > Géoconv semble utiliser par défaut > l'ellisoïde du WGS84. Or lorsque l'on regarde les paramètres de > projection pour les DOM (Gpe et Mqe) c'est l'ellisoïde de Hayford qui > est utilisé. (Je n'ai pas réussi à avoir exactement le système IGN, il y > a toujours des décalages) > > Mais ce n'est pas la seule explication au décalage des fichiers OSM de > l'outil de Fred Comment est-tu sûr que ça n'est pas la seule explication ? Il serait assez facile de modifier geoconv pour qu'il change d'ellipsoide. Est-ce que tu as deja essayé ? Il serait dommage d'appliquer un décalage constant sans comprendre les raisons. D'autres DOM utilisent l'UTM et il est probable que ces constantes ne s'y appliquent pas. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Résolution décalage Cadastre DOM-TOM
Bonjour à tous je vous livre les résultats de mes investigations pour le
cadastre dans les DOM. J'ai fais des vérifications graphiques sous
Quantum Gis d'un fichier échantillons de points extrait du cadastre en
ligne. La bibliothèque libre proj4 (dispo chez nos amis de l'OsGeo)
permet de configurer les paramètres de projections.
Dans cette bibliothèque on retrouve 'cs2cs' qui permet de convertir des
coordonnées entre deux systèmes géodésiques différents. L'avantage c'est
que cet utilitaire peut être très finement configuré (Ellipsoïde de
référence, Système géodésique etc..). Géoconv semble utiliser par défaut
l'ellisoïde du WGS84. Or lorsque l'on regarde les paramètres de
projection pour les DOM (Gpe et Mqe) c'est l'ellisoïde de Hayford qui
est utilisé. (Je n'ai pas réussi à avoir exactement le système IGN, il y
a toujours des décalages)
Mais ce n'est pas la seule explication au décalage des fichiers OSM de
l'outil de Fred
Régardez cette fiche géodésique de l'IGN:
http://geodesie.ign.fr/fiche_point_OM.asp?num_site=9710106&no_ptg=03
On va pouvoir tester grâce à ces coordonnées fiables les résultats de
geoconv et de cs2cs
-
Coordonnées Degrés Minutes Secondes
61 ° 29 ' 10.05520 ''Ouest 16 ° 15 ' 40.53420 ''Nord
Coordonnées Degrés Décimaux
61.48612644 16.261259500
Coordonnées XY WGS84
661 775,546 1 798 433,350
Coordonnées XY Système Sainte Anne -> Cadastre
662 198,180 1 798 736,709
-
Résultats Obtenus par transformation des Coord XY WGS84
code ligne de commande: echo "661775.546 1798433.350" | cs2cs -f %.16f
+proj=utm +zone=20N +to +proj=latlon -
-61.48612644(45438920)16.261259(4232077470) -> OK
Résultats Obtenus par transfo des Coord XY Ste Anne (Syst du Cadastre)
code ligne de commande: echo "662198.180 1798736.709" | cs2cs -f %.16f
+proj=utm +zone=20N +to +proj=latlon -
--Décalage--
-61.482151435039242016.2639725768512022
-
Résultats de GEOCONV sur système WGS84 XY
WGS84 -61.486126444(54062) 16.261259(424403377) > OK
--Décalage--
Résultats de GEOCONV sur système Ste Anne XY -> CADASTRE
WGS84 -61.48215143503598 16.26397257804702
-
Les outils sont donc fiables puisque l'on a jusqu'à la 7ème décimale les
mêmes résultats.Mais il faut partir des coordonnées XY WGS84.J'ai donc
effectué la différence entre les deux systèmes géodésiques et effectué
les transfos après le calcul suivant:
/
| X_wgs84=Xcadastre-422.634m
<
| Y_wgs84=Ycadastre-303.359m
\
Piti Schéma : Il faut donc décaler la grille cadastrale de 422.634m à
l'Ouest et de 303.359m au Sud pour avoir la WGS84
<- -422m ___C_C: Système Cadastrale
| |W: Système WGS84
-303m __W_| |
|| || |
v| ||__|
||
||
Tous les points géodésiques que j'ai pu controler ont cette
particularité à +-20cm ce qui me fait dire que sur un territoire comme
la Guadeloupe cette transformation est homogène.
J'ai dans la foulée pris des points de la côte Guadeloupéenne dans OSM
pour voir si par transformation inverse:
WGS84 (lat/lon) -> UTM20 Nord (X Y)
Je tombais dans l'Océan ou la Mer des Caraïbes ;-( et ... et ... Non ;-)
Donc la côte dans OSM à peu de chose est bien calée, les outils de
conversions sont fiables, le cadastre est fiable ;-$
J'ai donc modifié les scripts de l'Outil d'Import suivants comme suit:
conv-lambert.sh
java -jar tools/geoconv.jar -o WGS84 -deg -in "Lambert $lambertZone \
${1} \${2} 0" -out ''
"${inputFile}"
remplacé par:
awk '{printf "%.3f %.3f\n",$1-303.4,$2-422.6}' "${inputFile}" | cs2cs
-f %.16f +proj=utm +zone=20N +to +proj=latlon - | awk '{print "" }'
conv-lambert-gnuplot.sh
java -jar tools/geoconv.jar -o WGS84 -deg -in "UTM 20 N \${1} \${2} 0"
-out '' "${inputFile}"
remplacé par
awk '{printf "%.3f %.3f\n",$1-303.4,$2-422.6}' "${inputFile}" | cs2cs
-f %.16f +proj=utm +zone=20N +to +proj=latlon - | awk '{print "" }'
---
Explications des arguments:
Décalage des Systèmes géodésique
Colonne1($1 "X") - 303.4 et Colonne2($2 "Y")-422.6:
awk '{printf "%.3f %.3f\n",$1-303.4,$2-422.6}' "${inputFile}"
-f %.16f : sortie en degrée décimaux 16 décimales
+proj=utm +zone=20N +to +proj=latlon: Système de départ UTM20N
+to +proj=latlon : Système Géodésique d'arrivée Latitude/Longitude
WGS84
Tout ça injecté dans le tube pour Aw
