LayerMappingLien vers cette rubrique#La classe LayerMapping fournit une manière de faire correspondre du contenu provenant de fichiers de données spatiales (par ex. des fichiers shape) avec des modèles GeoDjango.
Cet utilitaire a été fabriqué à partir des besoins personnels de son auteur qui a ressenti le besoin d’éliminer de la répétition de code provenant de l’extraction d’objets géométriques et de champs de données à partir d’une couche vectorielle, de les convertir dans un autre système de coordonnées (par ex. WGS84) et de les insérer dans un modèle GeoDjango.
\n\n\nVous avez besoin d’une source de données prise en charge par GDAL, comme un fichier shape (nous utiliserons ici un fichier shape simple formé de trois polygones) :
\n>>> from django.contrib.gis.gdal import DataSource\n>>> ds = DataSource('test_poly.shp')\n>>> layer = ds[0]\n>>> print(layer.fields) # Exploring the fields in the layer, we only want the 'str' field.\n['float', 'int', 'str']\n>>> print(len(layer)) # getting the number of features in the layer (should be 3)\n3\n>>> print(layer.geom_type) # Should be 'Polygon'\nPolygon\n>>> print(layer.srs) # WGS84 in WKT\nGEOGCS["GCS_WGS_1984",\n DATUM["WGS_1984",\n SPHEROID["WGS_1984",6378137,298.257223563]],\n PRIMEM["Greenwich",0],\n UNIT["Degree",0.017453292519943295]]\nNous définissons ensuite le modèle Django correspondant (assurez-vous d’utiliser migrate) :
from django.contrib.gis.db import models\n\nclass TestGeo(models.Model):\n name = models.CharField(max_length=25) # corresponds to the 'str' field\n poly = models.PolygonField(srid=4269) # we want our model in a different SRID\n\n def __str__(self):\n return 'Name: %s' % self.name\nUtilisez LayerMapping pour extraire tous les éléments et les placer dans la base de données :
>>> from django.contrib.gis.utils import LayerMapping\n>>> from geoapp.models import TestGeo\n>>> mapping = {'name' : 'str', # The 'name' model field maps to the 'str' layer field.\n 'poly' : 'POLYGON', # For geometry fields use OGC name.\n } # The mapping is a dictionary\n>>> lm = LayerMapping(TestGeo, 'test_poly.shp', mapping)\n>>> lm.save(verbose=True) # Save the layermap, imports the data.\nSaved: Name: 1\nSaved: Name: 2\nSaved: Name: 3\nDans cet exemple, LayerMapping a transformé les trois objets géométriques du fichier shape de leur système de référence spatiale original (WGS84) vers le système de référence spatiale du modèle GeoDjango (NAD83). Si aucun système de référence spatiale n’avait été défini dans la couche, il aurait fallu employer le paramètre source_srs avec un objet SpatialReference pour en définir un.
LayerMappingLien vers cette rubrique#Voici les paramètres positionnels et nommés pouvant être utilisés durant la création d’instances d’objets LayerMapping.
Paramètre | \nDescription | \n
|---|---|
| \nLe modèle géographique, pas une instance. | \n
| \nLe chemin vers le fichier de source de données pris en charge par OGR (par ex. un fichier shape). Accepte aussi des instances de | \n
| \nUn dictionnaire : les clés sont des chaînes correspondant aux champs de modèle et les valeurs correspondent aux noms de champs des éléments OGR ou, dans le cas où le champ de modèle est géographique, au type géométrique OGR, par ex. | \n
Paramètres nommés | \n\n |
|---|---|
| \nL’indice de la couche à utiliser dans la source de données (0 par défaut). | \n
| \nUtile pour définir manuellement le système de référence spatiale de la source (par exemple pour les fichiers shape sans fichier | \n
| \nDéfinit le codage du jeu de caractères du contenu textuel dans la source de données OGR. Par exemple, | \n
| \nPeut être | \n
| \nQuand ce paramètre vaut | \n
| \nCe paramètre peut contenir un nom ou un tuple de noms du modèle concerné afin que les instances créées soient uniques pour le ou les noms de champs donnés. Les objets géométriques de chaque élément seront ajoutés à la collection associée au modèle unique. Le mode de transaction est forcé à | \n
| \nDéfinit la base de données à utiliser lors de l’importation de données spatiales. La valeur par défaut est | \n
save()Lien vers cette rubrique#La méthode save() accepte aussi des paramètres nommés. Ils sont utilisés pour contrôler la journalisation en sortie, le traitement des erreurs et pour l’importation de sous-ensembles d’éléments.
Paramètre nommé de | \nDescription | \n
|---|---|
| \nPeut être défini avec une segmentation ou un tuple | \n
| \nSi ce paramètre contient | \n
| \nPar défaut, les notifications d’erreurs non fatales sont affichées sur | \n
| \nLorsqu’il contient un nombre entier, définit l’intervalle d’enregistrement par transaction. Par exemple, si | \n
| \nLes informations de progression sont écrites sur ce flux fichier. Par défaut, il s’agit de | \n
| \nSi ce paramètre vaut | \n
| \nSi défini à | \n
Comme relevé dans l’avertissement en haut de cette section, Django mémorise toutes les requêtes SQL lorsque DEBUG=True. Définissez DEBUG=False dans vos réglages pour empêcher une consommation excessive de la mémoire lorsque vous exécutez les scripts LayerMapping.
max_allowed_packetLien vers cette rubrique#Si vous rencontrez l’erreur suivante lorsque vous utilisez la fonctionnalité LayerMapping avec MySQL :
OperationalError: (1153, "Got a packet bigger than 'max_allowed_packet' bytes")\nLa solution est alors d’augmenter la valeur du paramètre max_allowed_packet dans votre configuration de MySQL. Par exemple, la valeur par défaut peut être parfois aussi basse qu’un mégaoctet. Ce paramètre peut être modifié dans le fichier de configuration de MySQL (my.cnf) à la section [mysqld]:
max_allowed_packet = 10M\n