Visu. de données géolocalisées dans Google Earth

Ho! ça apparait ! Ho! ça disparait !

2006-12-08T00:57:00.000+01:00

Donc voici la suite de notre avancement du projet, nous avons supprimé la représentation persistante des icones/punaises.

ici une image global, on peut voir qu'il n'y a aucun icones/punaises à une altitude de vision très grande

apparition des punaises à une altitude <183km environ et disparition si altitude < 3km

apparition des icones à une altitude <93km environ et disparition si altitude < 3km

Bien sur tous ces seuils sont paramétrable.

Ca avance, ca avanceuh !!

2006-12-04T13:43:00.000+01:00

Voici le résultat que donne maintenant notre application ; xml -> moulinette -> kml

Nous pouvons voir qu'on a des icones supplémentaires. Ils nous permettent de palier le fait qu'on ne peut pas clicker sur les polygones.
Voici de plus près

Ca serai trop beau si tout marchait si bien :) Alors voici les problèmes qu'on a rencontré :
1) quand on click sur un icone (punaise) , ceux permette de sélectionner un polygone, dans la bar d'exploration à gauche. Nous n'avons pas la recentralisation total de la vue par rapport à ce polygon. C'est à dire que nous avons la centralisation en x,y mais pas la distance de vue.
2) problème des icones (punaise) qui restent visible même très loin

Nous essayons d'irrémédier à ces petits problèmes . Si vous voulez le document KML à tester demander le :), mais pour faire fonctionner notre fichier, il vous faudra avoir le dernier GE, la béta 4.

L'équipe de Visualisation de Données Géolocalisée dans Google Earth
(VDGGE)

Multipoligones et marqueurs

2006-11-22T11:03:00.000+01:00

A partir du dernier fichier de test de Julien, nous avons obtenu le fichier kml et la visualisation suivante

On peut y voir le multipolygone de la ville de Pau et celui de la ville de Toulouse. On peut y voir également des punaises representant des lieux bien précis.

Une vue plus proche du multipolygone de la ville de pau

Actuellement nous sommes en train de chercher la façon la plus optimale d'agencer les polygones afin que les plus grands soient en dessous des plus petits.

A suivre

Conversion d'un rectangle dans la projection de Lambert IIe en un polygone en WGS84

2006-11-11T15:32:00.000+01:00

Au vu des problèmes que posait une subdivision adaptative - en effet, l'approximation aurait été trop grossière en utilisant la géométrie euclidienne avec des points de coordonnées exprimées dans le système WGS84 - nous avons décidé de mettre en place une subdivision régulière.

Le programme écrit génére un fichier kml permettant la représentation d'une bounding box précisée en paramètre par les données x_min, y_min, x_max, y_max. Le nombre de subdivisions est choisi au début et est le même pour les quatres cotés. On pourra télécharger les classes composant ce programme sous la forme d'un projet NetBeans ici (il s'agit d'une archive rar : il vous faudra ajouter l'extension après chargement pour l'ouvrir...).

Voici un exemple avec l'une des bounding box du fichier de Laruns. Pour mémoire, il s'agit de celle_ci (la première du fichier Laruns) :

<bounding_box>
    <x_min> 366689.21875 </x_min>
    <y_min> 1758718.625 </y_min>
    <x_max> 383050.625 </x_max>
    <y_max> 1783151.375 </y_max>
</bounding_box>

Sur cet exemple, on distingue nettement la différence de forme :

* Approximation grossière avec seulement 4 sommets pour le polygône

* Avec 40 sommets

* Avec 120

* et enfin avec 400

Rmq : on constate que de 120 à 400 sommets, la forme n'a pas évolué de façon évidente.

Nous allons maintenant inclure ce travail au programme gérant la conversion des fichiers xml en kml écrit en parallèle.

Polygône grossièrement approximé

2006-10-24T21:53:00.000+02:00

Je viens d'écrire un boût de code permettant la génération d'un fichier kml affichant dans GoogleEarth un polygône grossièrement approximé (pour l'instant on se contente des quatres coins) à partir d'une bounding box (à savoir la donnée de x_max, x_min, y_max, y_min).

Exemple avec une bounding box inventée (nous ne sommes pas en possession de celle de Laruns et l'autre ne représente pas une surface assez étendue...)

x_min = 377159, x_max = 1796593
y_min = 388000, y_max = 1799999

On pourra consulter le fichier kml généré correspondant...

Remarque : la mise au point se fait automatiquement dans GoogleEarth lorsqu'on supprime les balises <LookAt></LookAt>

A suivre pour une subdivision plus précise...

Bounding Box en GML

2006-10-23T13:49:00.000+02:00

De manière à respecter au mieux les standards, Julien Lesbegueries à modifié le format des fichiers résultat XML de manière à coder nos propres bounding box dans un langage XML approprié aux information géographiques: le GML.

Ainsi, il faudra modifier le parsing des fichiers résultats pour lire les infos enrobées dans du GML. On ne vous demande pas d'être capable de lire tout le GML, mais il devrait être possible d'utiliser le schema XML pour le GML afin de parser les infos sur les bounding box.

Lecture et transformation des fichiers XML

2006-10-21T20:15:00.000+02:00

Après avoir cherché sur la toile les possibilités qui nous sont offertes avec le langage Java, il savère que l'API JDOM semble la plus simple et la plus complète à utiliser. On n'a pu tester que quelques possibilités que donne cet API, voici un petit exemple.

Avant : Exercice 2.xml
Avec : test.java
Après : ExerciceT.xml

Il reste encore quelques problèmes à régler comme l'écriture ainsi :
<tag>
      blabla1
      blabla2
      ...
</tag>

comme l'exgirerai la norme KML pour pouvoir décrire des polygones. Ainsi que l'ajout de la 2ème ligne d'un document pour dire que ce fichier est un fichier KML et non un XML.

Placement d'un rectangle - problèmes

2006-10-21T19:55:00.000+02:00

On a vu précédemment qu'un rectangle dans le système de coordonnées LambertIIe sera déformé en WGS84. En effet, cette projection ne conserve pas les lignes droites. Cependant, cette différence n'apparaît pas sur l'exemple traité sur le précédent post parce que la zone marquée n'est pas assez étendu. Julien Lesbegueries le confirme : l'écrasement du format WGS84 est relativement faible à l'échelle d'une commune comme Pau.

C'est pourquoi nous avons décidé de mettre en place une subdivision adaptative. En effet, nous allons prendre plusieurs points sur les cotés du triangle les convertir en WGS84 et comparer ce point théorique au point effectivement obtenu en se contentant de la ligne droite et les conserver si nous estimons que l'erreur est trop importante...

Cette méthode pose le problème du calcul des coordonnées des points placés sur le segment non encore modifié : on ne peut pas appliquer avec ces coordonnées les calculs standart de la géométrie euclidienne comme par exemple le calcul des coordonnées du milieu I du segment AB avec A(xa, ya) et B(xb, yb) : xi = (xa+xb)/2 et yi = (ya+yb)/2. Il en est de même pour le calcul de la distance, la distance euclidienne n'est pas adaptée... Après quelques recherches, il semblerait que ce calcul convienne :

6366*acos(cos(radians(lat_a))*cos(radians(lat_b))*cos(radians(long_b)-radians(long_a))+sin(radians(lat_a))*sin(radians(lat_b)))

(sources 1 et 2)

Je reposte dès que j'ai éclairci ces points...

En parallèle mes collègues ^^ travaillent sur DOM avec l'API JDOM...

Constatation du problème de placement d'un rectangle

2006-10-16T01:17:00.000+02:00

On s'attache maintenant à placer un rectangle dont les coordonnées en LambertIIe du point inférieur gauche sont (378224.65625, 1813021.375, 0) et ceux du coin supérieur droit sont (386235.46875, 1820997.375, 0) ; comme représenté ici :

Ainsi les coordonnées en LambertII des quatre coins sont respectivement : (378224.65625, 1813021.375, 0) ; (378224.65625, 1820997.375, 0) ; (386235.46875, 1820997.375, 0) et (386235.46875, 1813021.375, 0).
Si l'on se contente de convertir seulement ces quatres points du rectangle afin de créer le polygone correspondant dans GoogleEarth, voici le résultat obtenu :

Conversions :
(x, y, z) -> (lg, lt, h)
(378224.65625, 1813021.375, 0) -> (-0.3917342913, 43.2849178237, 0)
(378224.65625, 1820997.375, 0) -> (-0.3951439415, 43.3565455242, 0)
(386235.46875, 1820997.375, 0) -> (-0.296545993, 43.3590023576, 0)
(386235.46875, 1813021.375, 0) -> (-0.2932591947, 43.2873714423, 0)

voir le fichier KML correspondant

Si maintenant on utilise 8 points - les quatres coins et les milieux de chaque coté - pour construire ce polygone, on obtient :

Conversions :
(x, y, z) -> (lg, lt, h)
(378224.65625, 1813021.375, 0) -> (-0.3917342913, 43.2849178237, 0)
(378224.65625, 1817009.375, 0) -> (-0.3934380523, 43.3207311425, 0)
(378224.65625, 1820997.375, 0) -> (-0.3951439415, 43.3565455242, 0)
(382230.0625, 1820997.375, 0) -> (-0.3458460233, 43.3577852215, 0)
(386235.46875, 1820997.375, 0) -> (-0.296545993, 43.3590023576, 0)
(386235.46875, 1817009.375, 0) -> (-0.294901568, 43.323186368, 0)
(386235.46875, 1813021.375, 0) -> (-0.2932591947, 43.2873714423, 0)
(378224.65625, 1813021.375, 0) -> (-0.3917342913, 43.2849178237, 0)

nouveau fichier KML

On constate que le résultat n'est pas très différent... Mais en utilisant plusieurs autre points situés sur les cotés du rectangle on devrait s'apercevoir que cette projection est trop grossière...

Conversion LambertIIe <-> WGS84

2006-10-14T20:50:00.000+02:00

L'indication de M. Jobard (Le système de conversion lambertIIe n'est valide que sur le territoire français) résout le problème : toutes les coordonnées testés hier correspondaient à des lieux situés hors du territoire français...

Voici donc un exemple de conversion avec les coordonnées d'un lieu situé à proximité des Pyrénées d'abord avec l'interface graphique :

puis avec le petit programme écrit :

lpetit@Mimitux:~/Master/M2/TER/Convert_LIIWGS84/LIIeqWGS84$ java -jar dist/LIIeqWGS84.jar
------------------------------- USAGE ------------------------------
| java -opt A B C
| avec opt = toWGS84 pour convertir de LambertII a WGS84
| ou opt = toLambertII pour convertir de WGS84 a LambertII
| et A, B, C respectivement latitude, longitude, h dans le
| 1er cas et X, Y, Z dans le second
--------------------------------------------------------------------

lpetit@Mimitux:~/Master/M2/TER/Convert$ java -jar dist/LIIeqWGS84.jar toWGS84 378224.65625 1813021.375 0
latitude = 43.28491782368883
longitude = -0.39173429132516835
h = 0.0

lpetit@Mimitux:~/Master/M2/TER/Convert$ java -jar dist/LIIeqWGS84.jar toLambertII 43.28491782368883 -0.39173429132516835 0
X = 378225
Y = 1813021
Z = 0

Comme on peut le constater à travers cet exemple, le programme (v2 exécutable) fonctionne maintenant "parfaitement". Cependant, ces dernières lignes ont été obtenues après modifications de la classe écrite permettant la conversion dans les deux sens : il manquait encore une conversion degre -> radian (cf les commentaires dans le code pour plus de détails !) et une erreur s'était également glissé à l'utilisation de la méthode LambertIIe.create(WGS84).

Nous continuons donc à nous documenter sur le langage kml utilisé par GoogleEarth au travers des deux tutoriaux (KML 2.0 Tutorial, KML 2.1 Tutorial) qui nous ont été conseillé.

Travail sur la transformation des coordonnées géographiques du système LambertII dans le système géodésique mondial WGS84 (suite)

2006-10-14T00:48:00.000+02:00

L'utilisation de Netbeans a permis de résoudre le problème de compilation. En outre, la non-concordance des deux résultats provenait d'une stupide erreur de calcul. En effet, la méthode toWGS84() utilisée renvoie un objet de type WGS84 dont les données sont exprimées en radian. Il nous fallait donc effectuer une conversion finale radian -> degré pour obtenir le résultat exploitable dans GoogleEarth : l'erreur se situait à ce niveau (mauvais calcul !). Voici donc la classe finale :

On en a crée un exécutable jar et voici un petit exemple d'exécution :

lpetit@Mimitux:~/M2/TER/Convert$ java -jar LIItoWGS84.jar 10 10 0
latitude = 27.141064930752968
longitude = -3.4044722650195935
h = 0.0

Après suite à la remarque de Patrick Etcheverry, j'ai décidé de pousser l'exercice un tout petit peu plus loin en écrivant un programme semblable (exécutable jar) :

Cette deuxième version permet la conversion dans les deux sens :

* la commande java -jar LIIeqWGS84.jar toWGS84 10 10 0 a le même effet que précédemment

* quand la commande java -jar LIIeqWGS84.jar toLambertIIe latitude longitude h permet de convertir des coordonnées dans le système WGS84 à des coordonnées dans le système LambertIIe

Cependant les tests effectués ne sont pas concluants... et ce également dans l'interface graphique. Par exemple, en reprenant les nombres obtenus dans la conversion illustrée précédemment la réponse des deux programmes (geoconv et le notre donc) est la même, à savoir "out of LambertIIe zone"... Tous les tests effectués par la suite avec des nombres aléatoires apportent la même réponse.

Travail sur la transformation des coordonnées géographiques du système LambertII dans le système géodésique mondial WGS84

2006-10-13T01:36:00.000+02:00

Les informations sont localisées dans GoogleEarth à l'aide du système de coordonnées géodésique mondial WGS84. Or, l'application PIV renvoie des résultats localisés dans le système de coordonnées géograohiques propre à la France : Lambert II. C'est pourquoi nous avons travailler à découvrir l'API geoconv.

Dans un premier temps, nous avons testé ce petit programme avec les diffférentes possibilités proposées dans l'interface. Mais c'est seulement avec les options "Lenght in meters", "Angles in degrees", "LambertIIe" pour "Sources coordinates" et "WGS84" pour "Destination coordinates" pour convertir les données d'exemples (378224.65625, 386235.46875) que nous avons obtenu un "placemarks" situé dans la région des Pyrénées !

Ensuite, à titre d'exemple nous avons tenté d'écrire en JAVA et en s'appuyant sur les classes de geoconv un petit programme permettant de convertir les coordonnées françaises en des coordonnées exploitables dans GoogleEarth dont voici le code :

Mais cette classe pose des problèmes de compilation et semblerait fournir des résultats erronés... Par exemple pour x=10, y=10 et z=0 :

quand l'autre annonce : lg=-3.404472265°, lt=27.1410649308° et h=0 !

Cependant, nous avons découvert que geoconv permettait ce calcul très rapidemment en ligne de commande à l'aide de cette instruction java -jar geoconv.jar -o output_system input coordinates et permettait même la conversion de coordonnées contenues dans un fichier.

Affaire à suivre...