Dans l'éternelle quête d'un système simple et performant pour mettre en place un système d'édition de données spatiales via un navigateur web, de façon sécurisée et sur une base Postgres, il faut nous confronter au framework Django.

Cet article est une vulgarisation/fusion des deux tutoriels officels Django et GeoDjango. Ces derniers sont bien plus détaillés et vous les trouverez ici : 

• Tutoriel officiel Django : https://docs.djangoproject.com/fr/1.9/intro/tutorial01/
• Tutoriel officiel GeoDjango : https://docs.djangoproject.com/fr/1.9/ref/contrib/gis/tutorial/

Le tuto officiel Django se base sur les toutes dernières versions des outils, et sur Linux. En fonction de sa machine locale ou des serveurs web à notre disposition, il peut y avoir des différences. La syntaxe de certaines lignes de commande Django ou Python peuvent changer, ainsi que la façon d'appeler vos apps ou vos importations.

D'autre part faire ses 1^ers pas dans GeoDjango nécessite de s'être d'abord familiarisé à Django. On n'utilise pas ce module additionnel sans le framework complet.

Je vais donc tenter de clarifier tout cela, ne serait-ce qu'à mes yeux, et en allant rapidement vers les fontionnalités les plus basiques de GeoDjango. Au terme de cet article, nous aurons un système de CRUD sur de la donnée spatiale, en points, lignes et polygones, avec un fond OpenStreetMap, le tout accessible sur authentification.

Débutant complet sur Django, je liste ici mes grandes manips et étapes d'initiation, ça me servira de pense-bête, et peut-être que ça en aidera d'autres ! Un mémo liste les commandes récurrentes (Mémo Django/GeoDjango/Python). Un SCRUD spatial peut déjà être testé à cette adresse http://geodjango.hg-map.fr/admin/, un compte de test est disponible (identifiant : hgmap | mot de passe : identifiant à l'envers suivi de la somme de 100 et 23). Si le compte de test était super-user, l'interface afficherait également la gestion des utilisateurs.

Concernant l'installation des outils, si vous êtes sur Linux et que vous lisez ces lignes, c'est sans doute que vous pouvez vous en passez. Nous ne verrons les détails de l'installation que pour Windows. Le développement sera en revanche valable sur Linux et Windows (quelques lignes de commande qui diffèrent, pas plus).

---

Après avoir essayé de déployer un projet Django directement sur une machine Linux mutualisée de chez l'hébergeur Alwaysdata (pas facile quand on débute sur Python, et sur ce framework avec son propre serveur de développement, des librairies...), j'ai changé d'approche (mais nous reviendrons plus tard sur un déploiement en ligne chez cet hébergeur).

Tout d'abord, commençons en douceur par une installation locale sur un bon vieux Windows 7. Je ne pense pas qu'il y ait des différences notables sur les autres versions de Windows. Quant à Linux, la suite de cet article ainsi que le mémo listeront les commandes équivalentes pour une machine Debian GNU/Linux.

Django nécessite Python, installons-donc Python !

Installation locale

Python

Téléchargez Python sur le site officiel, mais privilégiez le fichier msi si vous êtes sous Windows (le fichier exe a réagi un peu bizarrement chez moi, pas d'erreur mais... rien). J'ai utilisé la version python-3.4.4.amd64.msi, téléchargeable ici (le lien Windows x86-64 MSI installer) :

https://www.python.org/downloads/windows/

Installer Python consiste à double-cliquer sur le fichier puis à cliquer sur Next... L'habitude semble être de mettre Python à la racine de C, ce qui va créer un répertoire Python34.

Si vous êtes utilisateur de SIG, vous avez peut-être un répertoire Python26 déjà présent. Ça ne pose aucun problème pour utiliser Python et Django. Le répertoire Python26 est une sorte d'instance de Python pour ArcGIS, une version Esri de Python en quelque sorte.

Très bien, mais si vous vérifiez maintenant la bonne installation de Python dans le shell (avec la commande python à la racine de C), vous n'avez pas forcément de confirmation. C'est normal, il faut que vous précisiez à Windows son path, via les fameuses variables d'environnement  (arrgghhh). Je vous laisse fouiller, il s'agira de modifier votre variable d'environnement Path pour ajouter tout à la fin ;C:\Python34\.

Une fois cela fait, la commande python vous renverra bien la version installée et quelques infos.

Pip

Sans doute une sorte de couche d'abstraction nécessaire à Django pour s'appuyer sur Python, ou alors un sous-environnement virtuel nécessaire à Python... On s'y intéressera plus tard. Pour l'heure il nous faut installer Pip avant de pouvoir installer Django. Une simple ligne de commande fera le job :

python -m pip install -U pip

En réalité Pip s'est déjà installé tout-à-l'heure, quand vous avez installé Python, mais vous verrez que Pip en profitera pour se mettre à jour. Si besoin en se désintallant et en se ré-installant.

Ou celle-ci : python -m pip install --upgrade pip

VirtualEnv

C'est notre environnement virtuel. Installons-le via la méthode très complexe qui consiste à entrer cette ligne de commande :

python -m pip install virtualenv

Si vous utilisez Windows, personne ici ne vous blâmera trop violemment, mais pensez bien à ajouter au début des lignes de commande tapant dans Python python -m. Et si vous êtes sur Linux, souvent il suffit de l'enlever, facile...

Django

Ah, enfin ! Si vous n'êtes pas trop fatigué, tapez la ligne suivante :

python -m pip install Django

Django va aller s'installer dans PythonXX/Lib/site-packages. Et en profite pour nous installer une base Sqlite, que nous n'utiliserons pas ici.

Vérification

On peut vérifier que Python parvient à accéder à Django. Ouvrez le shell Python (avec le fichier C:\PythonXX\python.exe par exemple), ou tapez python dans le shell Windows ou Linux (ce qui ouvre Python à l'intérieur du shell actif), vous voyez les >>>. Puis entrez :

import django; print(django.get_version())

Pour moi ce sera la version 1.9.2 de Django sous Windows en local ; et 1.6.4 sous Linux chez Alwaysdata.

1^er projet

Le répertoire du projet

Il y a toute une histoire de lien symbolique à créer sous Windows afin d'utiliser les fonction de django-admin ou de manage.py, pfou... Mais la ligne de commande suivante marchera tout aussi bien pour l'instant sous Windows, nous évitant de rentrer trop vite dans le gras. Placez-vous d'abord dans le répertoire voulu, et après avoir remplacé projet_django par le nom désiré :

python -m django startproject projet_django

Attention : contrairement à Wamp, la doc de Django déconseille de créer votre projet dans l'environnement virtuel ! Votre code serait accessible au visiteur paraît-il... Ne craignez rien et placez-vous bien à l'extérieur de votre environnement virtuel pour créer votre projet. La racine de C par exemple, sera parfaite pour vos 1^ers tests.

Si vous êtes sur une version plus ancienne de Django/Python et/ou sous Linux, la syntaxe peut varier. Rien de compliqué, voir le Mémo Django/GeoDjango/Python.

La création d'un projet Django avec cette commande aura pour effet de créer un 1^er répertoire du nom que vous avez choisi, à l'intérieur duquel se trouve un autre répertoire du même nom, c'est tout-à-fait normal. Typiquement sur un serveur web, vous entrez cette commande dans le répertoire www, htdocs, public, public_html... au moins pour développer et utiliser bientôt le serveur de développement.

Le tout 1^er répertoire qui s'est créé est donc le répertoire qui va contenir notre site, et qui pourra déjà être déplacé ou renommé (mais plus tard).

Une 1ère application dans le projet

Sous Linux ou Windows, après vous être placé à l'intérieur de votre projet Django déjà créé, tapez cette commande :

python manage.py startapp carto

J'ai choisi le nom carto comme nom de d'application, car nous allons rapidement tenter quelque chose... mais patience.

Un répertoire dûment nommé a été créé dans votre projet, et contient a minima selon votre version, les fichiers suivants :

• admin.py
• models.py
• tests.py
• views.py

Je crois que c'est à partir de la version 1.9 de Django que nous avons aussi un répertoire migrations et un fichier apps.py.dans l'arborescence du projet

Vous avez compris que nous allons pouvoir commencer à travailler. Mais d'abord une chose.

Lancer le serveur de développement

Placez-vous dans le répertoire de votre projet Django que vous venez de créer, puis exécutez :

python manage.py runserver

Et hop ! Par défaut votre serveur est accessible en local à l'adresse http://127.0.0.1:8000. Cela uniquement pendant que votre runserver est en marche, si vous le closez (en fermant le shell ou en faisant Ctrl+c), alors l'adresse ne fonctionnera plus.

Finalement, on vient juste d'utiliser manage.py, et directement dans notre projet pourtant situé en dehors de notre environnement virtuel ! En effet ce fichier se trouve à la racine de notre projet. Intéressant.

En fait à chaque fois qu'il faut se placer dans le répertoire de votre projet Django pour lancer une ligne de commande, c'est pour utiliser le fichier manage.py, qui permet d'appeler Python directement à partir de votre projet personnel.

Remarquez que le shell du runserver renvoie des infos à chaque requête sur le navigateur. Remarquez également que la page par défaut nous propose d'aller créer une 1^ère appli, cela alors que nous avons déjà notre appli carto et ses fichiers Python qui se sont créés. Humm, il y a sans doute un fichier de conf quelque part... Nous y viendrons en temps et en heure.

Pour l'équivalent Linux de la commande lançant le runserver, je crois qu'il n'y a qu'à enlever python, il y a aussi des subtilités si vous êtes déja sur un serveur distant. La commande peut prendre des paramètres comme un port spécifique par exemple. Voir le Mémo Django/GeoDjango/Python.

Postgres

Nous allons utiliser Postgres, un must pour Django (ou pour quoi que ce soit !). La suite de cet article suppose que vous avez à disposition une base Postgres SQL, distante ou local, avec de préférence son extension GIS d'installée.

La connexion de Postgres à Django nécessite Psycopg (enfin, pas forcément, mais ce sera plus confortable pour ce tutoriel). Si vous êtes toujours sur Windows, pour installer Psycopg :

python -m pip install psycopg2

Si Windows vous propose de mettre Pip à jour, faites donc.

Quant à l'accès à la BDD par Django, il se configure dans le fichier settings.py de votre projet, de façon très classique.

Une version complète du bloc DATABASES du fichier settings.py (aucune différence Windows/Linux et Django 1.6/1.9 tant qu'on ne cherche pas à utiliser GeoDjango et les champs géométriques) :

DATABASES = {
'default': {
'ENGINE': 'django.contrib.gis.db.backends.postgis',
'NAME': 'nom_de_bdd',
'USER': 'votre_user_bdd',
'PASSWORD': 'votre_mot_de_passe_de_user_bdd',
'HOST': 'votre_host_distant_ou_localhost',
}
}

D'ailleurs si vous ne comptez pas utiliser l'extension GIS de Postgres, mais simplement Postgres, l'ENGINE est plus simple : 'ENGINE': 'django.db.backends.postgresql',

Si vous êtes en local, vous mettez l'habituel localhost dans le HOST. Si vous n'avez pas de mot de passe pour la BDD, vous pouvez laisser ''.

Formulaire de connexion

Un certain nombre de fonctionnalités de Django sont présentes par défaut (les INSTALLED_APPS de votre fichier settings.py). Et certaines nécessitent la création de tables de données dédiées, qu'il vous faut créer en ligne de commande.

Sous les versions les plus récentes de Django/Python : python manage.py migrate

Sous Django 1.6 : python manage.py syncdb

La commande peut varier selon votre version de Django ou votre package, voyez le Mémo Django/GeoDjango/Python sur les différentes façons de générer les INSTALLED_APPS.

Après quoi, 6 tables préfixées par auth_ et 3 préfixées par django_ se sont créées :

• auth_group
• auth_group_permissions
• auth_permission
• auth_user
• auth_user_groups
• auth_user_user_permissions
• django_admin_log
• django_content_type
• django_session

Il se peut que le shell Django vous propose de créer un super-utilisateur, faites donc si besoin, en suivant les instructions.

Dans tous les cas, si vous relancez votre serveur de développement et que vous vous rendez à l'adresse :

http://127.0.0.1:8000/admin/

Un formulaire de connexion vous est déjà proposé.

Si vous avez déjà créer un utilisateur en ligne de commande précédement, connectez-vous !

Sinon la commande python ./manage.py createsuperuser vous permettra de créer un super-utilisateur Django.

Suivez les instructions qui vous demanderont de choisir un user, email et password.

1ères interfaces CRUD pour l'administration des utilisateurs

Après connexion en tant que super-utilisateur, vous avez accès à deux onglets Groups et Users. Prenez le temps de les explorer. Vous pouvez déjà créer de nouveaux utilisateurs et groupes via cette interface.

Dans les options des utilisateurs (si vous cliquez sur votre propre utilisateur par exemple), observez les tableaux du bas. Ils vous permettent de gérer des ACL.

Les ACL de 6 tables semblent déjà prêts-à-l'emploi.

Installation des bibliothèques spatiales

Quelques librairies vont être nécessaires à GeoDjango, il s'agit de GDAL, PROJ.4 et GEOS.

GDAL

Pour une installation sous Windows, des tutoriels déjà très complets existent, comme ces deux-ci :

• http://geotribu.net/node/636 (en français)
• https://pythongisandstuff.wordpress.com/2011/07/07/installing-gdal-and-ogr-for-python-on-windows/ (en anglais)

Je ne vais donc faire que lister quelques tips au sujet de cette installation, ça va peut-être vous faire gagner du temps.

Tout d'abord nous supposons que vous avez bien installé Python. Vous pouvez d'ailleurs ouvrir Python à partir du shell Windows, en tapant simplement python à la racine de C, puisque vous avez correctement configuré la variable d'environnement correspondante (voir la début de cet article, Installation locale).

Ceci vous permet de repérer avec certitude votre version de Windows et Python (vous en aurez besoin pour télécherger les bonnes versions des utilitaires GDAL). Si vous ouvrez Python vous avez par exemple comme moi :

Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 20:20:57) [MSC v.1600 64 bit (AMD64)] on win32

La version de Python de repère facilement. Pour Windows, ne vous faites pas avoir par le win32, la version de Windows est ici 1600 64 bit, c'est ça qu'il faut retenir.

Téléchargez les sources via le 1^er lien, en choisissant l'onglet qui vous correspond. Si vous avez la même version que moi, vous atterrirez sur le 2^ème lien.

• http://www.gisinternals.com/release.php
• http://www.gisinternals.com/query.html?content=filelist&file=release-1600-x64-gdal-1-11-3-mapserver-6-4-2.zip

En ce qui me concerne par exemple, j'ai téléchargé les fichiers :

• gdal-111-1600-x64-core.msi (le cœur de GDAL, à installer classiquement sur votre machine)
• GDAL-1.11.3.win-amd64-py3.4.msi (les bindings de Python, nécessaires pour faire communiquer votre instance Python et GDAL, nous les installerons plus tard)

Installez d'abord le cœur. Si vous êtes en 64 bits mais que GDAL s'est installée dans le répertoire des programmes en 32 bits (Programmes), déplacez-la dans le répertoire des programmes 64 bits, c'est plus sûr. Cela en coupant-collant le répertoire GDAL dans le répertoire Program Files (x86).

Vous avez maintenant 2 variables d'environnement à modifier/créer (aaaarghh) :

• GDAL_DATA, où personnellement j'ai mis C:\Program Files (x86)\GDAL\gdal-data. Vous pouvez modifier celle existante (en connaissance de cause, si vous êtes utilisateur de Postgres par exemple, il y en a sûrement déjà une). Cette variable ne doit possèder qu'un seul chemin, n'en rajoutez pas un 2^ème.
• L'éternelle variable Path, où j'ai ajouté ;C:\Program Files (x86)\GDAL.

Cela fait, vous pouvez vérifier le bonne installation de GDAL en tapant par exemple gdal_grid dans le shell Windows (l'un des utilitaires GDAL disponibles), cela dès la racine puisque vous avez précisez des bonnes variables d'environnement. Si la commande vous renvoie des infos sur les options disponibles pour cet utilitaire, c'est que tout va bien (cela même si les infos se terminent par ...datasource is not specified, c'est normal). Sinon, vous avez sans doute un problème de variable d'environnement...

Attention : Windows a tendance a renommer symboliquement le répertoire des programmes 32 bits (Programmes). En réalité son vrai nom aux yeux de la machine est Program Files, et c'est bien sûr ce nom qu'il faut utiliser dans vos variables d'environnement. Si vous avez un doute, faites un clic-droit/Propriétés sur un répertoire ou fichier à l'intérieur, et observez son chemin complet.

Bindings Python

Installons maintenant les bindings Python. L'installateur vous proposera de cibler l'instance Python à viser, si vous en avez plusieurs (les utilisateurs ArcGIS notamment), choisissez la bonne (la nôtre).

Vous pouvez vérifiez que les bindings sont bien pris en compte en appelant GDAL dans Python :

python pour ouvir le shell Python, puis import gdal

Si vous avez un saut de ligne Python classique (>>>), sans erreur ni ...module introuvable..., c'est que tout va bien.

PROJ.4 et GEOS avec OSGeo

Pour les librairies PROJ.4 et GEOS, nous allons jouer les fainéants, puisque le package OSGeo4W devrait nous installer les 2 librairies nécessaires (+ une multitude d'autres que vous pouvez parcourir dans l'installateur). Sélectionnez bien GDAL dans l'installateur, même si nous avons déjà la nôtre, ça ne posera pas problème. Vous le téléchargez selon votre version de Windows (32 ou 64 bits), ici :

• https://trac.osgeo.org/osgeo4w/

Le téléchargement des paquets est un peu long, puis l'installation est classique. Ce package s'installe à la racine de C, tant mieux, nous ne nous embêterons pas avec les répertoires 32 et 64 bits...

Nous avons tout de même à retoucher nos variables d'environnement, pour ajouter dans le Path quelque chose qui devrait ressembler à cela si vous êtes en 64 bits (sinon modifiez) :

;C:\OSGeo4W64

Cela suffira pour appeler GEOS. En revanche, PROJ.4 nécessite la création/modification d'une nouvelle variable, de ce type :

• PROJ_LIB : C:\OSGeo4W64\share\proj

Comme GDAL_DATA, cette variable ne doit pas être en double, modifiez celle éventuellement existante (en connaissance de cause). Ensuite tentez un proj dans le shell Windows, à la racine, pour vérification.

Remarquez que nous aurions pu installer GDAL de cette façon, nous aurions sans doute gagner du temps, mais enfin cela nous a permis de nous faire la main... D'autre part je n'ai pas bien compris où l'installateur OSGeo planquait le répertoire gdal-data. Du coup je préfère l'installation manuelle pour cette lib.

Remarquez que dans Python la commande import osgeo est correcte, mais je ne sais plus si un outil OSGeo était déjà nativement présent dans Python ou pas...

Dès le chapitre suivant, nous saurons si nos bibliothèques spatiales fonctionnent.

Création du modèle d'une couche de points

Nous allons créer notre 1^ère couche de points grâce à GeoDjango. Cela en commençant par en créer le modèle, Django et son ORM sauront ensuite générer la table correspondante.

GeoDjango est un module déjà nativement présent dans Django, puisque pour l'utiliser il nous suffira de l'appeler. Cependant GeoDjango nécessite certaines librairies que vous avez sans doute déjà installeés.

Éditons le fichier models.py de notre application carto déjà créée. Remplacez son éventuel contenu par ces lignes :

from django.contrib.gis.db import models
import datetime
from django.utils import timezone

class Sample(models.Model):
# Champs classiques
name = models.CharField("Name", max_length=100)
author = models.CharField("Author", max_length=100)
pub_date = models.DateTimeField("Moment")
type = models.CharField("Type", max_length=100)
description = models.CharField("Description", max_length=100)
structure = models.CharField("Structure", max_length=100)

# Champ geometrique
geom = models.PointField("Location")

# Chaine du modele
def __str__(self):
return self.name

Attention à l'indentation, qui doit être respectée (4 espaces). Mais si besoin Python vous renverra des erreurs avec leurs lignes concernées.

Le 1^er paragraphe contient nos éventuelles importations d'options nécessaires (les from et import). Remarquez que nous avons remplacé notre modèle par défaut par django.contrib.gis.db, c'est notre façon de demander à ce fichier de modèles d'utiliser GeoDjango.

En effet juste en-dessous, un objet Sample définit une table et ses champs, et l'un de ces champs est justement de type géométrique (PointField).

Remarquez que nous ne prenons pas la peine de créer un champ id, Django s'en occupera pour nous. Tant mieux...

Le dernier paragraphe définit la chaine du modèle. Remarquez que name n'est pas un mot spécial, mais reprend bien le champ name que vous vous apprêtez à créer.

L'absence d'accent dans mes commentaires n'est pas anodin, en effet Python est très à cheval sur les encodages et les tracasseries qu'il y a autour. Je ne prendrais donc aucun risque ici.

À ce stade la génération de la table ne donnera rien, car si le fichier de modèles de notre application carto est bien au courant qu'il doit utiliser le module GeoDjango, Django lui-même ne le sait pas encore. Il ne sait même pas que notre application carto existe. Allons lui dire.

Déclarations des applications installées

Sous Django 1.6 vous allez déclarer vos apps dans le fichier settings.py de votre projet en ajoutant les deux dernières lignes de ce bloc des INSTALLED_APPS. Votre bloc ressemble maintenant à cela :

INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.gis',
'carto',
)

Sous Django 1.9 vous déclarez vos applications personnelles légèrement différemment. De cette façon pour notre application carto : 

'carto.apps.CartoConfig',

Encore une fois : attention à l'indentation !

Votre projet Django sait maintenant qu'il doit utiliser le module GIS de Django (django.contrib.gis) et qu'une application est déjà présente (carto).

Vous pouvez maintenant générer la table (syncdb ou migrate selon votre version de Django, voir le Mémo Django/GeoDjango/Python).

Une table carto_sample a été créée, préfixée du nom de notre application, et contenant bien nos champs (et un champ id).

Remarquez que le champ geom a été parfaitement créée, quelque soit notre version de Postgres, avec des types de contraintes dont je ne connaissais même pas l'existence (trois CHECK automatiques semble-t-il, du SRID, de la dimension et du type de géométrie). De même si vous êtes sur une version 9.0 de Postgres, remarquez que Django a correctement ajouté une entrée à la table geometry_columns. Sans plus d'information de notre part, Django a choisi le SRID 4326, correspondant à une projection mondiale courante sur le web.

Django et son ORM font vraiment bien le boulot ! Mais au fait : où est notre interface ?

Édition cartographique

Pour afficher la vue correspondante à notre modèle de points dans l'interface d'administration déjà existante, il nous la créer dans le fichier admin.py de votre application carto. Remplacez son éventuel contenu par ce code :

from django.contrib.gis import admin

from .models import Sample

class SampleAdmin(admin.OSMGeoAdmin):

fieldsets = [
('Identity', {'fields': ['name', 'pub_date']}),
('Detail', {'fields': ['author', 'type', 'description', 'structure']}),
(None, {'fields': ['geom']}),
]

admin.site.register (Sample, SampleAdmin)

Rafraîchissez votre page d'administration (relancez le serveur de développement si besoin). Un nouveau groupe d'onglet Carto est apparu, avec un premier onglet Samples.

Nous utilisons une administration GeoDjango un peu particulière (OSMGeoAdmin) afin de bénéficier tout de suite d'un fond de carte OpenStreetMap, plus précis que le basemap par défaut.

N'hésitez pas à saisir un enregistrement. Sans plus d'information de notre part dans le modèle, tous les champs sont obligatoires. Le point sera bien enregistré dans notre champ géométrique Postgres.

Les champs sont ici groupés en onglets, de nombreuses autres options sont possibles, à la fois sur le formulaire d'un sample mais aussi sur leur tableau. Ajoutez ces lignes à la suite de votre option fieldsets par exemple :

list_filter = ['pub_date']
search_fields = ['name']

Et rafraîchissez le tableau des samples...

Vous pouvez aussi allez voir les ACL des utilisateurs, de nouveaux sont disponibles concernant votre objet Sample.

Installation en ligne chez Alwaysdata

Alwaysdata propose des hébergements Django, et fournit un petit tutoriel pour l'aide au déploiement, ici :

https://help.alwaysdata.com/languages/python/django

Python et Django sont nativement installés chez eux, mais dans des versions un peu anciennes pour l'instant (sigh !). Ça devrait évoluer prochainement, sinon vous pouvez déjà monter en version en utilisant ce didacticiel non-officiel je crois :

http://forum.alwaysdata.com/viewtopic.php?id=4620

Always propose une formule gratuite de départ, ou des hébergements mutualisés payants très intéressants (JNTPPE : je ne travaille pas pour eux).

Le conseil d'Alwaysdata est de bien vérifier que votre serveur de développement intégré à Django fonctionne, avant d'essayer de passer sur le serveur de production.

Pensez à bien donner les droits d'exécution à votre fichier django.fcgi (et à l'enregistrer au format Unix, et pas DOS !) :

chmod +x django.fcgi

Il y a également des subtilités sur la syntaxe de la ligne de commande démarrant le serveur de développement chez eux. En effet on doit y mentionner notre nom de compte et le port souhaité (et avant faire une demande de port auprès du support, très rapide). Voir le Mémo Django/GeoDjango/Python.