CONVERSION LAT/LONG EN COORDONNÉES UTM
ScSami
Messages postés
1488
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
3 décembre 2007
-
16 févr. 2006 à 23:41
Euskadia Messages postés 1 Date d'inscription mardi 27 juillet 2010 Statut Membre Dernière intervention 28 mars 2011 - 28 juil. 2010 à 15:23
Euskadia Messages postés 1 Date d'inscription mardi 27 juillet 2010 Statut Membre Dernière intervention 28 mars 2011 - 28 juil. 2010 à 15:23
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/36090-conversion-lat-long-en-coordonnees-utm
https://codes-sources.commentcamarche.net/source/36090-conversion-lat-long-en-coordonnees-utm
28 juil. 2010 à 15:23
15 déc. 2009 à 09:10
4 juin 2008 à 14:46
14 mai 2008 à 07:51
Je suis débutant, je n'arrive pas à mettre dans un fichier excel les fichiers extraits de fichier.zip
convert_UTM3.frm
Convert_UTM3.vbp
Convert_UTM3.vbw
CONVUTM3.bas
MSSCCPRJ.SCC
Y a t il une façon de faire?
merci
12 janv. 2008 à 21:11
15 nov. 2007 à 14:39
une version pour PDA est-elle toujours d'actualité ?
Merci
Alain
23 janv. 2007 à 19:14
Bon courage
Maurice
23 janv. 2007 à 16:01
Merci aussi a CADRATURE pour ses conseils mais avec Visual Basic.NET ça s'arrange....
8 janv. 2007 à 20:39
C'est mieux
'Première vérification
'Vérification WGS84 fuseau 31
'IGN 681136,676368 5614137,94606
'VB6 681196,802972 5614141,28008
'Deuxième vérification Prg 2
'VB6 681114,870098069 5614130
Il faudrait relire les différentes remarques et les appliquer
Merci
Maurice
7 janv. 2007 à 19:38
1 août 2006 à 10:01
Extra
Maurice
31 juil. 2006 à 19:22
je ne sais pas si quelqu'un est encore intéressé par ce code...
Les erreurs de positionnement constatées proviennent des constantes utilisées.
PI = 3.14159265359
Pour le système WGS84 (GPS donc), dans module.vbp :
modifier e = 8.18191908426215E-02 ( et non 0.8 !)
eccSquared = 0.00669438
eccPrimeSquared = 0.006739497
Ainsi, en comparant avec Circé (l'outils fourni par IGN), l'erreur constatée se situe sur la 3ème décimale...
C'est quand même bien de savoir qu'on a pas foutu les pompes sur un poil de puce !
Côté programmation, éviter les variables globales...
Bon courage et merci.
25 févr. 2006 à 23:27
20 févr. 2006 à 10:25
Vérification WGS84 fuseau 31
IGN 681136,676368 5614137,94606
VB6 681196,802972 5614141,28008
Le type des variable devrait être double autant que possible
Revoir les types de variables pour une meilleure précision
A bientôt
Maurice
20 févr. 2006 à 09:54
Merci pour le code qui fonctionne mais je n'ai pas vérifier son exactitude
Il est inutile de redéclarer les variables dans la form mais il est utile dans le module de les déclarer as Integer
A bientôt
Maurice
17 févr. 2006 à 09:46
Dans la ligne suivante
Dim b, f, e, deg_RAD, longrad, latgrad, latgrade_J6, one_e2 As Double
Seule la variable one_e2 est de type Double
Dans d'autres circonstances (et pas dans ce code) cela peut être gênant et produire des erreurs. Voir exemple ci-dessous.
Il vaut mieux séparer les déclarations
Dim b as Double
Dim f as Double
Dim e as Double
etc...
ou bien
Dim b as Double, f as Double, e as Double etc...
========================================
Exemple:
======
Dim A, E, G, B As Double
Dim C As Double
B = 2.07
A = B
E = 3
C = test(B)
'C = test(A) << argument type mismatch
Debug.Print VarType(A) ' = 5 vbDouble
Debug.Print VarType(B) ' = 5 vbDouble
Debug.Print VarType(E) ' = 2 vbInteger
Debug.Print VarType(G) ' = 0 vbEmpty (uninitialized)
Public Function test(paramB As Double) As Double
Dim dResult As Double
dResult = 10 * paramB
test = dResult
End Function
17 févr. 2006 à 09:00
16 févr. 2006 à 23:41