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

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 !!

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

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

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é

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

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

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

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...