LayerMapping data import utilityLink to this heading#The LayerMapping class provides a way to map the contents of\nvector spatial data files (e.g. shapefiles) into GeoDjango models.
This utility grew out of the author’s personal needs to eliminate\nthe code repetition that went into pulling geometries and fields out of\na vector layer, converting to another coordinate system (e.g. WGS84), and\nthen inserting into a GeoDjango model.
\n\n\nYou need a GDAL-supported data source, like a shapefile (here we’re using\na simple polygon shapefile, test_poly.shp, with three features):
>>> 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]]\nNow we define our corresponding Django model (make sure to use 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\nUse LayerMapping to extract all the features and place them in the\ndatabase:
>>> 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\nHere, LayerMapping transformed the three geometries from the shapefile\nin their original spatial reference system (WGS84) to the spatial reference\nsystem of the GeoDjango model (NAD83). If no spatial reference system is\ndefined for the layer, use the source_srs keyword with a\nSpatialReference object to specify one.
LayerMapping APILink to this heading#The following are the arguments and keywords that may be used during\ninstantiation of LayerMapping objects.
Argument | \nDescription | \n
|---|---|
| \nThe geographic model, not an instance. | \n
| \nThe path to the OGR-supported data source file\n(e.g., a shapefile). Also accepts\n | \n
| \nA dictionary: keys are strings corresponding to\nthe model field, and values correspond to\nstring field names for the OGR feature, or if the\nmodel field is a geographic then it should\ncorrespond to the OGR geometry type,\ne.g., | \n
Keyword Arguments | \n\n |
|---|---|
| \nThe index of the layer to use from the Data Source\n(defaults to 0) | \n
| \nUse this to specify the source SRS manually (for\nexample, some shapefiles don’t come with a | \n
| \nSpecifies the character set encoding of the strings\nin the OGR data source. For example, | \n
| \nMay be | \n
| \nSetting this to False will disable coordinate\ntransformations. In other words, geometries will\nbe inserted into the database unmodified from their\noriginal state in the data source. | \n
| \nSetting this to the name, or a tuple of names,\nfrom the given model will create models unique\nonly to the given name(s). Geometries from\neach feature will be added into the collection\nassociated with the unique model. Forces\nthe transaction mode to be | \n
| \nSets the database to use when importing spatial data.\nDefault is | \n
save() Keyword ArgumentsLink to this heading#The save() method also accepts keywords. These keywords are\nused for controlling output logging, error handling, and for importing\nspecific feature ranges.
Save Keyword Arguments | \nDescription | \n
|---|---|
| \nMay be set with a slice or tuple of\n(begin, end) feature ID’s to map from\nthe data source. In other words, this\nkeyword enables the user to selectively\nimport a subset range of features in the\ngeographic data source. | \n
| \nWhen this keyword is set, status information\nwill be printed giving the number of features\nprocessed and successfully saved. By default,\nprogress information will be printed every 1000\nfeatures processed, however, this default may\nbe overridden by setting this keyword with an\ninteger for the desired interval. | \n
| \nBy default, non-fatal error notifications are\nprinted to | \n
| \nIf set with an integer, transactions will\noccur at every step interval. For example, if\n | \n
| \nStatus information will be written to this file\nhandle. Defaults to using | \n
| \nExecution of the model mapping will cease upon\nthe first error encountered. The default value\n( | \n
| \nIf set, information will be printed\nsubsequent to each model save\nexecuted on the database. | \n
As noted in the warning at the top of this section, Django stores all SQL\nqueries when DEBUG=True. Set DEBUG=False in your settings, and this\nshould stop excessive memory use when running LayerMapping scripts.
max_allowed_packet errorLink to this heading#If you encounter the following error when using LayerMapping and MySQL:
OperationalError: (1153, "Got a packet bigger than 'max_allowed_packet' bytes")\nThen the solution is to increase the value of the max_allowed_packet\nsetting in your MySQL configuration. For example, the default value may\nbe something low like one megabyte – the setting may be modified in MySQL’s\nconfiguration file (my.cnf) in the [mysqld] section:
max_allowed_packet = 10M\n