Afin de faciliter les opérations d’enregistrement et de récupération de données géométriques il est d’usage d’utiliser la librairie Java JTS dont les types de géométrie peuvent être directement enregistrés en base de donnée (Oracle ou PostgreSQL+Postgis) grâce, par exemple, à Hibernate Spatial. C’est le format utilisé en standard par la librairie Geotools. Malheureusement il existe un problème dans BlazeDS qui conduit à une mauvaise sérialisation/dessérialisation des objets JTS, ceux-ci ne contiennent aucune propriété valable après avoir été traités par le marshaller ; il est dont impossible de les faire transiter en l’état entre le client et le serveur. Grâce à l’utilisation des BeanProxy et du PropertyProxyRegistry nous avons pu redéfinir la liste des propriétés à considérer pour les objet de type com.vividsolutions.jts.geom.Point et com.vividsolutions.jts.geom.Polygon ; et ainsi modifier la façon dont elles sont traitées (en overridant les méthodes getValue et setValue de la class BeanProxy). Les objets de type géométrie transitent donc en toute transparence entre l’application Flex/Flash et l’application serveur+BDD. Ceci est particulièrement util pour le dessin sur carte avec sauvegarde des objets géométriques créés par l’utilisateur et apporte un gain de temps considérable dans la réalisation d’un projet avec module cartographique.
Exemple pour Polygon :
PropertyProxyRegistry.getRegistry().register(com.vividsolutions.jts.geom.Polygon.class, new BlazeDSGeometryUtils.JTSPolygonProxy());
static class JTSPolygonProxy extends BeanProxy
{
@Override
public List getPropertyNames(Object instance)
{
List newList = new ArrayList();
newList.add("SRID");
newList.add("area");
newList.add("coordinate");
newList.add("coordinates");
newList.add("numPoints");
newList.add("dimension");
newList.add("length");
newList.add("geometryType");
return newList;
}
}
Cas des systèmes de projection :
La librairie OpenScales n’offre pas autant de méthodes de projection de coordonnées que Geotools ; il peut être utile d’effectuer les conversions d’un système de projection à un autre directement sur le serveur pour s’affranchir des limitations imposées par OpenScales. On peut citer par exemple le système Lambert II étendu qui n’est supporté que dans la dernière version d’OpenScales — réservée à Flex 4. Pour éviter de fastidieuses et répétitives tâches de conversion au sein des fonctions d’enregistrement et de requêtage nous avons choisi de les implémenter directement dans la redéfinition des fonctions du BeanProxy. En effet, en déclarant à BlazeDS les propriétés des objets Point et Polygon il est tout à fait possible d’en ajouter plus que nécessaire, et notamment une propriété contenant le code du système de projection voulu après la sérialisation/désérialisation. Il suffit alors, dans la surcharge des méthodes setValue et getValue, d’agir sur les coordonnées en fonction du système désiré. De cette manière nous pouvons travailler en coordonnées Long/Lat dans l’application Flex et enregistrer les données en système métrique — Lambert II étendu ou 93 par exemple — dans lequel une requête portant sur la distance entre plusieurs points sera nettement moins coûteuse en ressources.
Commentaires