Python : les bases de données géospatiales - 2) mapping objet-relationnel (ORM, SQLAlchemy, SQLObject, GeoAlchemy, Django-GeoDjango, TurboGears ou MapFish)

Le billet précédent 'Python les bases de données géospatiales, traitement classique, principes et problèmes" a introduit le terme "mapping objet-relationnel".

Selon Wikipedia, la définition est  :

"Un mapping objet-relationnel (en anglais object-relational mapping ou ORM) est une technique de programmation informatique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé. On pourrait le désigner par « correspondance entre monde objet et monde relationnel".

Ceci veut dire, plus simplement ici, que toutes les tables SQL seront transformées en classes Python et que tous les traitements (query, jointures, héritages, etc.) ne concerneront plus que des relations entre objets Python. Les deux techniques possibles sont expliquées dans la figure suivante (liaisons tables SQL - classes Python créés par un "mapper" ou directes).

Parmi les modules qui utilisent cette technique les plus connus sont SQLAlchemy ou SQLObject mais aussi des frameworks web comme Django, Turbogears, web2py ou Pylons.  Leur principe est simple pour un programmeur, une fois connecté à une base de données, il ne s'occupe plus que de Python. 

Nous n'allons pas essayer ici d'expliquer toutes leurs spécificités ni d'en faire un tutoriel, car il y en a un très grand nombre sur Internet, très bien faits et  même des livres qui leur sont consacrés (personnellement, j'utilise le livre "Essential SQLAlchemy" de Rick Copeland chez O'Reilly, plus de 200 pages...). Nous nous contenterons ici de les "effleurer" dans le cadre des données spatiales pour montrer leurs avantages et leurs problèmes et nous nous contenterons des modules (soit les principes des frameworks web sont équivalents, soit ils utilisent SQLAlchemy).

Malgré sa relative complexité, SQLAlchemy sera choisi pour en développer les principes de base, car il permet de les exposer de la manière la plus claire. Les modules d'accès aux bases de données sont évidemment toujours nécessaires, mais leurs disparités sont uniformisées par le processus nommé "engine" (moteur ?)  et une fois connecté, plus de traces apparentes de SQL.

 Le mapper ou lien est fait entre la table "cartes" par l'entremise de "macarte" (création) ou "matable" (récupération) et la classe Carte. A partir de ce moment, tous les traitements (créations de tables, requêtes, mises à jour, suppressions, jointures, etc.) se feront en Python à partir de la classe Carte

a = Carte()

SQLAlchemy est très puissant et ses fondements, ébauchés ici, sont valables pour tous les autres modules. Dans un premier temps, un autre module, SQLObject, sera utilisé pour les exemples, car il est plus simple à appréhender.

Application (avec le module SQLObject)

L'opération sera effectuée avec la base Postgis abordée dans l'article précédent:

from sqlobject import *
 
#connexion
db='postgres://localhost:5432/testpostgis'
connection = connectionForURI(db)
 
#puisque la table existe déjà dans la base,on récupère directement 
#ses caractéristiques dans la classe, puis les types des champs peuvent être redéfinis
 
class testpoly(SQLObject): 
    _connection = connection
    _fromDatabase = True
    nom = StringCol()
    the_geom = StringCol()# type geometry dans la base physique testpoly
 
poly = testpoly.get(1)
print poly.nom
'test1'
print poly.the_geom
'01030000000100000007000000B64939E22648B73F210C2F0B83D7E93F0399366B2021C23F5B07A42CAEA5E93FA3A3B4CC6E14D73F3164C5F9C377E63FAB25B136C9D8CE3F179603F45D89E13FD2DA533F623EB63FB4B2452B5BB4E23FA1C950507AE0AB3FA12E64C5F9C3E73FB64939E22648B73F210C2F0B83D7E93F'

Cela à l'air magique la première fois que l'on utilise un de ces modules, mais pour réellement comprendre ce qu'ils font, il suffit d'ajouter une ligne (de débogage):

testpoly._connection.debug = True

testpoly._connection.debug = True
a = testpoly.get(1)
 1/QueryOne:  SELECT nom, the_geom FROM testpoly WHERE ((testpoly.id) = (1))
 1/QueryR  :  SELECT nom, the_geom FROM testpoly WHERE ((testpoly.id) = (1))
 1/COMMIT  :  auto

Et tout s'éclaire, car "ils ne font que" masquer les requêtes SQL, mais, somme toute, c'est le principe du mapping relationel objet. La procédure est néanmoins totalement différente. Il est tout à fait possible de travailler virtuellement en Python seul (base de données en mémoire) d'effectuer tous les traitements (création de tables, insertion de valeurs, requêtes, etc.), et de n'envoyer les résultats en SQL (sous forme de curseur) à la base de données physique que selon notre bon vouloir. Le rôle du curseur est donc fortement minimisé.

Le résultat obtenu ici est la géométrie brute au format WKB (Well Known Binary, de l' OGC). Comment transformer cette valeur en format compréhensible par Python ? Dans la démarche traditionnelle, la requête utilisée faisait appel à des fonctions propres à Postgis, AsText(the_geom) et Srid(the_geom).

Ces modules offrent toujours une possibilité d'effectuer des requêtes brutes en SQL

b = testpoly._connection.queryOne("""SELECT nom, AsText(the_geom), Srid(the_geom) FROM testpoly""")
 
print b
('test1', 'POLYGON((0.09094470046083 0.807557603686636,0.141635944700461 0.80147465437788,0.360622119815668 0.702119815668203,0.240990783410138 0.548018433179723,0.086889400921659 0.584516129032258,0.054447004608295 0.742672811059908,0.09094470046083 0.807557603686636))', 4326)

Mais on retombe évidemment dans les travers de la première démarche.

Il serait difficile de trouver un artifice en Python pour "masquer" cette requête SQL propre à Postgis. La solution réside dans la possibilité offerte par une classe de modifier les résultats obtenus. Ainsi, le module Shapely, déjà vu, permet de transformer le format WKB en WKT:

from shapely.wkb import loads
class testpoly(SQLObject):
    _connection = connection
    _fromDatabase = True
    nom = StringCol()
    the_geom = StringCol()
    # modification du résulat à l'aide du module shapely qui sait décoder le format wkb
    def _get_the_geom(self):
        valeur=self._SO_get_the_geom()
        res = loads(valeur.decode('hex')).wkt
        return res
 a = testpoly.get(1)
 print a.the_geom
'POLYGON ((0.0909447004608300 0.8075576036866360, 0.1416359447004610 0.8014746543778800, 0.3606221198156680 0.7021198156682030, 0.2409907834101380 0.5480184331797230, 0.0868894009216590 0.5845161290322580, 0.0544470046082950 0.7426728110599080, 0.0909447004608300 0.8075576036866360))'

La structure objet de ces modules permet donc d'ajouter facilement de nouvelles classes Python pour traiter ces problèmes. Les premières ont été proposées par info.bycycle.org/2007/01/29/using-postgis-with-sqlalchemy/ et sgillies.net/blog/531/the-shapely-alchemist/ sur base de modules externes, mais ceux-ci ne disposent pas de toutes les possibilités de Postgis. D'autres se sont donc mis à traiter directement les fonctions de Postgis, sans passer par un module externe. Parmi ceux-ci, SQLAlchemy lui-même (svn.sqlalchemy.org/sqlalchemy/trunk/examples/postgis/postgis.py) ou  une "surcouche" nommée GeoAlchemy, entièrement dédiée aux bases de données géospatiales (le module ajoute une classe supplémentaire nommée geoalchemy). Le module n'en est qu'à sa première version, mais il est déjà prometteur (avec encore quelques bugs...)

from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
from geoalchemy import *
 
#création de l'"engine"
engine = create_engine('postgres://moi@localhost/testpostgis') # l'instruction ",echo=True" 
#placée ici, aurait le même effet que la commande de débogage de SQLObject 
 
# ouverture d'une session de travail
session = sessionmaker(bind=engine)()
 
# métadonnées
metadata = MetaData(engine)
Base = declarative_base(metadata=metadata)
 
 
#récupération de la table testpoly dans la classe Testpoly 
class Testpoly(Base):
     __tablename__= 'testpoly'
     __table_args = {'autoload': True}
     the_geom = GeometryColumn(Polygon(2))
 
#requête
s = session.query(Testpoly).get(1)
#ou
s = session.query(Testpoly).first()
#géométrie
print session.scalar(s.geom.geometry_type)
'ST_Polygon'
# géométrie en texte wkt
print session.scalar(s.geom.wkt)
'POLYGON((0.09094470046083 0.807557603686636,0.141635944700461 0.80147465437788,0.360622119815668 0.702119815668203,0.240990783410138 0.548018433179723,0.086889400921659 0.584516129032258,0.054447004608295 0.742672811059908,0.09094470046083 0.807557603686636))'
 
#géométrie en gml
print session.scalar(s.geom.gml)
'<gml:Polygon srsName="EPSG:4326"><gml:outerBoundaryIs><gml:LinearRing><gml:coordinates>0.09094470046083,0.807557603686636 0.141635944700461,0.80147465437788 0.360622119815668,0.702119815668203 0.240990783410138,0.548018433179723 0.086889400921659,0.584516129032258 0.054447004608295,0.742672811059908 0.09094470046083,0.807557603686636</gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Polygon>'
 
#géométrie en kml
print session.scalar(s.geom.kml)
'<Polygon><outerBoundaryIs><LinearRing><coordinates>0.09094470046083,0.807557603686636 0.141635944700461,0.80147465437788 0.360622119815668,0.702119815668203 0.240990783410138,0.548018433179723 0.086889400921659,0.584516129032258 0.054447004608295,0.742672811059908 0.09094470046083,0.807557603686636</coordinates></LinearRing></outerBoundaryIs></Polygon>'

GeoAlchemy permet aussi directement d'utiliser des fonctions similaires à celles présentes dans Postgis comme:

#Création de géométries:
wkt = "POLYGON((....))"
essai = Testpoly(nom="test3", geom=WKTSpatialElement(wkt))
wkt2 = "POLYGON((....))"
essai2 = Testpoly(nom="test4", geom=WKTSpatialElement(wkt))
session.add_all([essai1,essai2])
session.commit()
# et les analyses spatiales:
session.query(Testpoly).filter(Testpoly.geom.touches(uneautregéométrie)).count()
# + buffer, intersection, convex hull..;

Lors du dernier PyCon 2010 (conférence des utilisateurs Python), Sanjiv Singh, l'auteur de Geoalchemy a montré comment l'intégrer à TurboGears pour en faire un framework web spatial (us.pycon.org/media/2010/talkdata/PyCon2010/016/tg2-geospatial-pycon2010.pdf). Il offre une demonstration de ce framework avec des manipulations Geoalchemy à geo.turbogears.org/geoalchemydemo

D'autres solutions de webmapping geospatial sont aussi basées sur ces principes comme GeoDjango, maintenant intégré à Django ou MapFish (tutoriels dans les liens)

Conclusions

Dans le domaine géospatial, les solutions de mapping objet-relationnel prennent de plus en plus d'importance et il serait dommage de passer à côté lorsque l'on développe en Python, que soit pour des scripts ou pour du webmapping. Dans leur souci de neutralité vis à vis-à-vis du SQL et des bases de données (un même script peut s'appliquer à tous les cas, en changeant une seule ligne, l'engine), il est cependant nécessaire de suivre les évolutions (mises à jour et classes supplémentaires en fonction des évolutions d'une base de données). 

Mais une fois bien maitrisés, cela devient un réel plaisir de ne plus devoir s'arracher les cheveux avec du SQL et de se consacrer uniquement à Python.

Voilà pourquoi michalisavraam.org/2010/02/7-wishes-for-the-new-geoprocessor/, entre autres, souhaiterait un même traitement pour le module Argisscripting d'ESRI.

Tous les traitements ont été effectués sur Mac OS X avec Python 2.5.4 et Inkscape pour les figures.