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.48612644444444444444444444444444 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.4821514350392420    16.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 '<trkpt lat="${2.3}" lon="${2.2}"></trkpt>'
"${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 "<trkpt
lat=\"" $2 "\" lon=\"" $1 "\"></trkpt>" }'


------------------------------------------------------------------------
conv-lambert-gnuplot.sh
------------------------------------------------------------------------

java -jar tools/geoconv.jar -o WGS84 -deg -in "UTM 20 N \${1} \${2} 0"
-out '<trkpt lat="${2.3}" lon="${2.2}"/>' "${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 "<trkpt
lat=\"" $2 "\" lon=\"" $1 "\"/>" }'

-----------------------------------------------------------------------
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 Awk qui formate ce beau monde en XML:

<trkpt lat="YY°.16décimales" lon="XX°.16décimales"/>
ou
<trkpt lat="YY°.16décimales" lon="XX°.16décimales"/></trkpt>

-----------------------------------------------------------------------

Au final le tracé GPX et le fichier OSM est toujours décalé malgré mes
modifs (je m'en suis arraché les cheveux ... Rogntuju @ * + )

Sniff !

J'ai été sauvé par le fichier de points polyline.xxxxxxxxx.points.
En effet quand je lui applique ce piti script c'est PARFAIT !

awk '{printf "%.3f %.3f\n",$1-422.634,$2-303.359}'
fichier.polyline.points | cs2cs -f %.16f +proj=utm +zone=20N +to
+proj=latlon - | awk '{print $1 " " $2}'> fichier_commune_calé_WGS84.txt

Il est exploitable directement dans Qgis par le plugin "delimited_text"
ou "GPXable" par le piti script Awk ci-dessus ++.

Et là c'est magnifique ! Ca MARCHE !

WouOuuHouu ! Enfin ! KeskeséBeauLeLogicieLibre !

Fred tu as une idée du script (ruby ou autre) qui décalerait les points
GNUPlot ?

Pieren j'espère qu'on pourra avancer sur cette histoire de décalage ! et
trouver les bons paramètres dans "cs2cs". Je ne sais pas si l'on pourra
faire une passerelle vers Java ...
Je vous tiens au courant quand j'ai du nouveau! Qqs Vérifs et Tests en
Cours

Références:
Site Proj4
http://trac.osgeo.org/proj/

Manuel de cs2cs:
http://trac.osgeo.org/proj/wiki/man_cs2cs

Paramétrage de Qgis et Doc Projection Tous Territoires Français
http://lambert93.ign.fr/fileadmin/files/IGNF-spatial_ref_sys.sql

Article Wikipédia Awk
http://fr.wikipedia.org/wiki/Awk


VOili VOilou !
"YaPluKa" rendre tout cela un peu plus propre ! 8-) et tout documenter
dans le Wiki.
J'espère ne pas avoir été trop long ! 
Bonne Nuit *-)


_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à