LayerMapping data import utility

This utility grew out of the author’s personal needs to eliminate the code repetition that went into pulling geometries and fields out of a vector layer, converting to another coordinate system (e.g. WGS84), and then inserting into a GeoDjango model.

注解

Use of requires GDAL.

警告

GIS data sources, like shapefiles, may be very large. If you find that LayerMapping is using too much memory, set to False in your settings. When DEBUG is set to True, Django every SQL query — and when SQL statements contain geometries, this may consume more memory than is typical.

2. Now we define our corresponding Django model (make sure to use migrate):

Here, transformed the three geometries from the shapefile in their original spatial reference system (WGS84) to the spatial reference system of the GeoDjango model (NAD83). If no spatial reference system is defined for the layer, use the source_srs keyword with a SpatialReference object to specify one.

class LayerMapping(model, data_source, mapping, layer=0, source_srs=None, encoding=None, transaction_mode=’commit_on_success’, transform=True, unique=True, using=’default’)

The following are the arguments and keywords that may be used during instantiation of LayerMapping objects.

Support for data_source was added.

LayerMapping.``save(verbose=False, fid_range=False, step=False, progress=False, silent=False, stream=sys.stdout, strict=False)

The save() method also accepts keywords. These keywords are used for controlling output logging, error handling, and for importing specific feature ranges.

As noted in the warning at the top of this section, Django stores all SQL queries when DEBUG=True. Set DEBUG=False in your settings, and this should stop excessive memory use when running LayerMapping scripts.

If you encounter the following error when using LayerMapping and MySQL: