mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

Fixed #14141: docs now use the :doc: construct for links between documents.

Browse Source 
Thanks, Ramiro Morales.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13608 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jacob Kaplan-Moss
2010-08-19 19:27:44 +00:00
parent a352154e42
commit 728effcfbd
181 changed files with 1222 additions and 1525 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/ref/contrib/gis/admin.txt
View File

@@ -54,7 +54,7 @@ GeoDjango's admin site
existing geometry fields in the admin.
.. note::
This is different from adding the geometry field to
:attr:`~django.contrib.admin.ModelAdmin.readonly_fields`,
which will only display the WKT of the geometry. Setting

2
docs/ref/contrib/gis/commands.txt
View File

@@ -78,6 +78,6 @@ of using ``ogrinspect`` :ref:`in the tutorial <ogrinspect-intro>`.
all applicable fields.
.. django-admin-option:: --srid
The SRID to use for the geometry field. If not set, ``ogrinspect`` attempts
to automatically determine of the SRID of the data source.

44
docs/ref/contrib/gis/db-api.txt
View File

@@ -14,7 +14,7 @@ Spatial Backends
.. versionadded:: 1.2
In Django 1.2, support for :ref:`multiple databases <topics-db-multi-db>` was
In Django 1.2, support for :doc:`multiple databases </topics/db/multi-db>` was
introduced. In order to support multiple databases, GeoDjango has segregated
its functionality into full-fledged spatial database backends:
@@ -26,7 +26,7 @@ its functionality into full-fledged spatial database backends:
Database Settings Backwards-Compatibility
-----------------------------------------
In :ref:`Django 1.2 <releases-1.2>`, the way
In :doc:`Django 1.2 </releases/1.2>`, the way
to :ref:`specify databases <specifying-databases>` in your settings was changed.
The old database settings format (e.g., the ``DATABASE_*`` settings)
is backwards compatible with GeoDjango, and will automatically use the
@@ -60,7 +60,7 @@ MySQL's spatial extensions only support bounding box operations
[``Contains``, ``Crosses``, ``Disjoint``, ``Intersects``, ``Overlaps``,
``Touches``, ``Within``]
according to the specification. Those that are implemented return
the same result as the corresponding MBR-based functions.
the same result as the corresponding MBR-based functions.
In other words, while spatial lookups such as :lookup:`contains <gis-contains>`
are available in GeoDjango when using MySQL, the results returned are really
@@ -92,8 +92,8 @@ model)::
>>> z.save()
Moreover, if the ``GEOSGeometry`` is in a different coordinate system (has a
different SRID value) than that of the field, then it will be implicitly
transformed into the SRID of the model's field, using the spatial database's
different SRID value) than that of the field, then it will be implicitly
transformed into the SRID of the model's field, using the spatial database's
transform procedure::
>>> poly_3084 = GEOSGeometry('POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))', srid=3084) # SRID 3084 is 'NAD83(HARN) / Texas Centric Lambert Conformal'
@@ -133,17 +133,17 @@ For example::
>>> qs = Zipcode.objects.filter(poly__contains=pnt)
In this case, ``poly`` is the geographic field, :lookup:`contains <gis-contains>`
is the spatial lookup type, and ``pnt`` is the parameter (which may be a
is the spatial lookup type, and ``pnt`` is the parameter (which may be a
:class:`~django.contrib.gis.geos.GEOSGeometry` object or a string of
GeoJSON , WKT, or HEXEWKB).
A complete reference can be found in the :ref:`spatial lookup reference
A complete reference can be found in the :ref:`spatial lookup reference
<spatial-lookups>`.
.. note::
GeoDjango constructs spatial SQL with the :class:`GeoQuerySet`, a
subclass of :class:`~django.db.models.QuerySet`. The
GeoDjango constructs spatial SQL with the :class:`GeoQuerySet`, a
subclass of :class:`~django.db.models.QuerySet`. The
:class:`GeoManager` instance attached to your model is what
enables use of :class:`GeoQuerySet`.
@@ -156,8 +156,8 @@ Introduction
------------
Distance calculations with spatial data is tricky because, unfortunately,
the Earth is not flat. Some distance queries with fields in a geographic
coordinate system may have to be expressed differently because of
limitations in PostGIS. Please see the :ref:`selecting-an-srid` section
coordinate system may have to be expressed differently because of
limitations in PostGIS. Please see the :ref:`selecting-an-srid` section
in the :ref:`ref-gis-model-api` documentation for more details.
.. _distance-lookups-intro:
@@ -181,7 +181,7 @@ The following distance lookups are available:
Distance lookups take a tuple parameter comprising:
#. A geometry to base calculations from; and
#. A geometry to base calculations from; and
#. A number or :class:`~django.contrib.gis.measure.Distance` object containing the distance.
If a :class:`~django.contrib.gis.measure.Distance` object is used,
@@ -191,8 +191,8 @@ to be in the units of the field.
.. note::
For users of PostGIS 1.4 and below, the routine ``ST_Distance_Sphere``
is used by default for calculating distances on geographic coordinate systems
For users of PostGIS 1.4 and below, the routine ``ST_Distance_Sphere``
is used by default for calculating distances on geographic coordinate systems
(e.g., WGS84) -- which may only be called with point geometries [#fndistsphere14]_.
Thus, geographic distance lookups on traditional PostGIS geometry columns are
only allowed on :class:`PointField` model fields using a point for the
@@ -212,24 +212,24 @@ to be in the units of the field.
You can tell GeoDjango to use a geography column by setting ``geography=True``
in your field definition.
For example, let's say we have a ``SouthTexasCity`` model (from the
`GeoDjango distance tests`__ ) on a *projected* coordinate system valid for cities
For example, let's say we have a ``SouthTexasCity`` model (from the
`GeoDjango distance tests`__ ) on a *projected* coordinate system valid for cities
in southern Texas::
from django.contrib.gis.db import models
class SouthTexasCity(models.Model):
name = models.CharField(max_length=30)
# A projected coordinate system (only valid for South Texas!)
# A projected coordinate system (only valid for South Texas!)
# is used, units are in meters.
point = models.PointField(srid=32140)
point = models.PointField(srid=32140)
objects = models.GeoManager()
Then distance queries may be performed as follows::
>>> from django.contrib.gis.geos import *
>>> from django.contrib.gis.measure import D # ``D`` is a shortcut for ``Distance``
>>> from geoapp import SouthTexasCity
>>> from geoapp import SouthTexasCity
# Distances will be calculated from this point, which does not have to be projected.
>>> pnt = fromstr('POINT(-96.876369 29.905320)', srid=4326)
# If numeric parameter, units of field (meters in this case) are assumed.
@@ -294,7 +294,7 @@ Lookup Type PostGIS Oracle MySQL [#]_ SpatiaLite
``GeoQuerySet`` Methods
-----------------------
The following table provides a summary of what :class:`GeoQuerySet` methods
are available on each spatial backend. Please note that MySQL does not
are available on each spatial backend. Please note that MySQL does not
support any of these methods, and is thus excluded from the table.
==================================== ======= ====== ==========
@@ -330,7 +330,7 @@ Method PostGIS Oracle SpatiaLite
:meth:`GeoQuerySet.translate` X X
:meth:`GeoQuerySet.union` X X X
:meth:`GeoQuerySet.unionagg` X X X
==================================== ======= ====== ==========
==================================== ======= ====== ==========
.. rubric:: Footnotes
.. [#fnwkt] *See* Open Geospatial Consortium, Inc., `OpenGIS Simple Feature Specification For SQL <http://www.opengis.org/docs/99-049.pdf>`_, Document 99-049 (May 5, 1999), at Ch. 3.2.5, p. 3-11 (SQL Textual Representation of Geometry).

4
docs/ref/contrib/gis/deployment.txt
View File

@@ -54,7 +54,7 @@ Example::
number of ``processes`` instead.
For more information, please consult Django's
:ref:`mod_wsgi documentation <howto-deployment-modwsgi>`.
:doc:`mod_wsgi documentation </howto/deployment/modwsgi>`.
``mod_python``
--------------
@@ -84,7 +84,7 @@ Example::
else your GeoDjango application may crash Apache.
For more information, please consult Django's
:ref:`mod_python documentation <howto-deployment-modpython>`.
:doc:`mod_python documentation </howto/deployment/modpython>`.
Lighttpd
========

10
docs/ref/contrib/gis/feeds.txt
View File

@@ -1,5 +1,3 @@
.. _ref-gis-feeds:
================
Geographic Feeds
================
@@ -8,10 +6,10 @@ Geographic Feeds
:synopsis: GeoDjango's framework for generating spatial feeds.
GeoDjango has its own :class:`Feed` subclass that may embed location information
in RSS/Atom feeds formatted according to either the `Simple GeoRSS`__ or
in RSS/Atom feeds formatted according to either the `Simple GeoRSS`__ or
`W3C Geo`_ standards. Because GeoDjango's syndication API is a superset of
Django's, please consult `Django's syndication documentation <ref-contrib-syndication>`
for details on general usage.
Django's, please consult :doc:`Django's syndication documentation
</ref/contrib/syndication>` for details on general usage.
.. _W3C Geo: http://www.w3.org/2003/01/geo/
@@ -28,7 +26,7 @@ API Reference
.. class:: Feed
In addition to methods provided by
In addition to methods provided by
the :class:`django.contrib.syndication.feeds.Feed`
base class, GeoDjango's ``Feed`` class provides
the following overrides. Note that these overrides may be done in multiple ways::

110
docs/ref/contrib/gis/geoquerysets.txt
View File

@@ -14,12 +14,12 @@ GeoQuerySet API Reference
Spatial Lookups
===============
Just like when using the the :ref:`queryset-api`, interaction
Just like when using the the :ref:`queryset-api`, interaction
with ``GeoQuerySet`` by :ref:`chaining filters <chaining-filters>`.
Instead of the regular Django :ref:`field-lookups`, the
spatial lookups in this section are available for :class:`GeometryField`.
For an introduction, see the :ref:`spatial lookups introduction
For an introduction, see the :ref:`spatial lookups introduction
<spatial-lookups-intro>`. For an overview of what lookups are
compatible with a particular spatial backend, refer to the
:ref:`spatial lookup compatibility table <spatial-lookup-compatibility>`.
@@ -31,7 +31,7 @@ bbcontains
*Availability*: PostGIS, MySQL, SpatiaLite
Tests if the geometry field's bounding box completely contains the lookup
Tests if the geometry field's bounding box completely contains the lookup
geometry's bounding box.
Example::
@@ -53,7 +53,7 @@ bboverlaps
*Availability*: PostGIS, MySQL, SpatiaLite
Tests if the geometry field's bounding box overlaps the lookup geometry's
Tests if the geometry field's bounding box overlaps the lookup geometry's
bounding box.
Example::
@@ -277,9 +277,9 @@ the values given in the given pattern. This lookup requires a tuple parameter,
PostGIS & SpatiaLite
~~~~~~~~~~~~~~~~~~~~
On these spatial backends the intersection pattern is a string comprising
nine characters, which define intersections between the interior, boundary,
and exterior of the geometry field and the lookup geometry.
On these spatial backends the intersection pattern is a string comprising
nine characters, which define intersections between the interior, boundary,
and exterior of the geometry field and the lookup geometry.
The intersection pattern matrix may only use the following characters:
``1``, ``2``, ``T``, ``F``, or ``*``. This lookup type allows users to "fine tune"
a specific geometric relationship consistent with the DE-9IM model. [#fnde9im]_
@@ -302,7 +302,7 @@ Oracle
~~~~~~
Here the relation pattern is compreised at least one of the nine relation
strings: ``TOUCH``, ``OVERLAPBDYDISJOINT``, ``OVERLAPBDYINTERSECT``,
strings: ``TOUCH``, ``OVERLAPBDYDISJOINT``, ``OVERLAPBDYINTERSECT``,
``EQUAL``, ``INSIDE``, ``COVEREDBY``, ``CONTAINS``, ``COVERS``, ``ON``, and
``ANYINTERACT``. Multiple strings may be combined with the logical Boolean
operator OR, for example, ``'inside+touch'``. [#fnsdorelate]_ The relation
@@ -312,7 +312,7 @@ Example::
Zipcode.objects.filter(poly__relate(geom, 'anyinteract'))
Oracle SQL equivalent::
Oracle SQL equivalent::
SELECT ... WHERE SDO_RELATE(poly, geom, 'anyinteract')
@@ -403,7 +403,7 @@ overlaps_left
*Availability*: PostGIS
Tests if the geometry field's bounding box overlaps or is to the left of the lookup
Tests if the geometry field's bounding box overlaps or is to the left of the lookup
geometry's bounding box.
Example::
@@ -422,7 +422,7 @@ overlaps_right
*Availability*: PostGIS
Tests if the geometry field's bounding box overlaps or is to the right of the lookup
Tests if the geometry field's bounding box overlaps or is to the right of the lookup
geometry's bounding box.
Example::
@@ -440,7 +440,7 @@ overlaps_above
*Availability*: PostGIS
Tests if the geometry field's bounding box overlaps or is above the lookup
Tests if the geometry field's bounding box overlaps or is above the lookup
geometry's bounding box.
Example::
@@ -458,7 +458,7 @@ overlaps_below
*Availability*: PostGIS
Tests if the geometry field's bounding box overlaps or is below the lookup
Tests if the geometry field's bounding box overlaps or is below the lookup
geometry's bounding box.
Example::
@@ -476,7 +476,7 @@ strictly_above
*Availability*: PostGIS
Tests if the geometry field's bounding box is strictly above the lookup
Tests if the geometry field's bounding box is strictly above the lookup
geometry's bounding box.
Example::
@@ -494,7 +494,7 @@ strictly_below
*Availability*: PostGIS
Tests if the geometry field's bounding box is strictly above the lookup
Tests if the geometry field's bounding box is strictly above the lookup
geometry's bounding box.
Example::
@@ -662,7 +662,7 @@ Keyword Argument Description
===================== =====================================================
``field_name`` By default, ``GeoQuerySet`` methods use the first
geographic field encountered in the model. This
keyword should be used to specify another
keyword should be used to specify another
geographic field (e.g., ``field_name='point2'``)
when there are multiple geographic fields in a model.
@@ -670,7 +670,7 @@ Keyword Argument Description
used on geometry fields in models that are related
via a ``ForeignKey`` relation (e.g.,
``field_name='related__point'``).
``model_att`` By default, ``GeoQuerySet`` methods typically attach
their output in an attribute with the same name as
the ``GeoQuerySet`` method. Setting this keyword
@@ -679,12 +679,12 @@ Keyword Argument Description
``qs = Zipcode.objects.centroid(model_att='c')`` will
attach the centroid of the ``Zipcode`` geometry field
in a ``c`` attribute on every model rather than in a
``centroid`` attribute.
``centroid`` attribute.
This keyword is required if
a method name clashes with an existing
``GeoQuerySet`` method -- if you wanted to use the
``area()`` method on model with a ``PolygonField``
This keyword is required if
a method name clashes with an existing
``GeoQuerySet`` method -- if you wanted to use the
``area()`` method on model with a ``PolygonField``
named ``area``, for example.
===================== =====================================================
@@ -705,12 +705,12 @@ each element of this GeoQuerySet.
.. method:: GeoQuerySet.distance(geom, **kwargs)
This method takes a geometry as a parameter, and attaches a ``distance``
attribute to every model in the returned queryset that contains the
This method takes a geometry as a parameter, and attaches a ``distance``
attribute to every model in the returned queryset that contains the
distance (as a :class:`~django.contrib.gis.measure.Distance` object) to the given geometry.
In the following example (taken from the `GeoDjango distance tests`__),
the distance from the `Tasmanian`__ city of Hobart to every other
In the following example (taken from the `GeoDjango distance tests`__),
the distance from the `Tasmanian`__ city of Hobart to every other
:class:`PointField` in the ``AustraliaCity`` queryset is calculated::
>>> pnt = AustraliaCity.objects.get(name='Hobart').point
@@ -732,7 +732,7 @@ the distance from the `Tasmanian`__ city of Hobart to every other
Because the ``distance`` attribute is a
:class:`~django.contrib.gis.measure.Distance` object, you can easily express
the value in the units of your choice. For example, ``city.distance.mi`` is
the distance value in miles and ``city.distance.km`` is the distance value
the distance value in miles and ``city.distance.km`` is the distance value
in kilometers. See the :ref:`ref-measure` for usage details and the list of
:ref:`supported_units`.
@@ -867,9 +867,9 @@ then 4326 (WGS84) is used by default.
geometry is placed on the models.
.. note::
What spatial reference system an integer SRID corresponds to may depend on
the spatial database used. In other words, the SRID numbers used for Oracle
What spatial reference system an integer SRID corresponds to may depend on
the spatial database used. In other words, the SRID numbers used for Oracle
are not necessarily the same as those used by PostGIS.
Example::
@@ -903,7 +903,7 @@ to each element of the ``GeoQuerySet`` that is the result of the operation.
.. method:: GeoQuerySet.difference(geom)
Returns the spatial difference of the geographic field with the given
geometry in a ``difference`` attribute on each element of the
geometry in a ``difference`` attribute on each element of the
``GeoQuerySet``.
@@ -913,7 +913,7 @@ geometry in a ``difference`` attribute on each element of the
.. method:: GeoQuerySet.intersection(geom)
Returns the spatial intersection of the geographic field with the
given geometry in an ``intersection`` attribute on each element of the
given geometry in an ``intersection`` attribute on each element of the
``GeoQuerySet``.
``sym_difference``
@@ -937,7 +937,7 @@ geometry in an ``union`` attribute on each element of the
Geometry Output
---------------
The following ``GeoQuerySet`` methods will return an attribute that has the value
The following ``GeoQuerySet`` methods will return an attribute that has the value
of the geometry field in each model converted to the requested output format.
``geohash``
@@ -967,8 +967,8 @@ Attaches a ``geojson`` attribute to every model in the queryset that contains th
===================== =====================================================
Keyword Argument Description
===================== =====================================================
``precision`` It may be used to specify the number of significant
digits for the coordinates in the GeoJSON
``precision`` It may be used to specify the number of significant
digits for the coordinates in the GeoJSON
representation -- the default value is 8.
``crs`` Set this to ``True`` if you want the coordinate
@@ -988,8 +988,8 @@ __ http://geojson.org/
*Availability*: PostGIS, Oracle
Attaches a ``gml`` attribute to every model in the queryset that contains the
`Geographic Markup Language (GML)`__ representation of the geometry.
Attaches a ``gml`` attribute to every model in the queryset that contains the
`Geographic Markup Language (GML)`__ representation of the geometry.
Example::
@@ -1000,9 +1000,9 @@ Example::
===================== =====================================================
Keyword Argument Description
===================== =====================================================
``precision`` This keyword is for PostGIS only. It may be used
to specify the number of significant digits for the
coordinates in the GML representation -- the default
``precision`` This keyword is for PostGIS only. It may be used
to specify the number of significant digits for the
coordinates in the GML representation -- the default
value is 8.
``version`` This keyword is for PostGIS only. It may be used to
@@ -1019,9 +1019,9 @@ __ http://en.wikipedia.org/wiki/Geography_Markup_Language
*Availability*: PostGIS
Attaches a ``kml`` attribute to every model in the queryset that contains the
`Keyhole Markup Language (KML)`__ representation of the geometry fields. It
should be noted that the contents of the KML are transformed to WGS84 if
Attaches a ``kml`` attribute to every model in the queryset that contains the
`Keyhole Markup Language (KML)`__ representation of the geometry fields. It
should be noted that the contents of the KML are transformed to WGS84 if
necessary.
Example::
@@ -1033,8 +1033,8 @@ Example::
===================== =====================================================
Keyword Argument Description
===================== =====================================================
``precision`` This keyword may be used to specify the number of
significant digits for the coordinates in the KML
``precision`` This keyword may be used to specify the number of
significant digits for the coordinates in the KML
representation -- the default value is 8.
===================== =====================================================
@@ -1054,11 +1054,11 @@ the `Scalable Vector Graphics (SVG)`__ path data of the geometry fields.
Keyword Argument Description
===================== =====================================================
``relative`` If set to ``True``, the path data will be implemented
in terms of relative moves. Defaults to ``False``,
in terms of relative moves. Defaults to ``False``,
meaning that absolute moves are used instead.
``precision`` This keyword may be used to specify the number of
significant digits for the coordinates in the SVG
``precision`` This keyword may be used to specify the number of
significant digits for the coordinates in the SVG
representation -- the default value is 8.
===================== =====================================================
@@ -1129,7 +1129,7 @@ dissolving boundaries.
*Availability*: PostGIS, Oracle
Returns the extent of the ``GeoQuerySet`` as a four-tuple, comprising the
Returns the extent of the ``GeoQuerySet`` as a four-tuple, comprising the
lower left coordinate and the upper right coordinate.
Example::
@@ -1163,7 +1163,7 @@ Example::
*Availability*: PostGIS
Returns a ``LineString`` constructed from the point field geometries in the
Returns a ``LineString`` constructed from the point field geometries in the
``GeoQuerySet``. Currently, ordering the queryset has no effect.
Example::
@@ -1184,25 +1184,25 @@ use of ``unionagg`` is processor intensive and may take a significant amount
of time on large querysets.
.. note::
If the computation time for using this method is too expensive,
consider using :meth:`GeoQuerySet.collect` instead.
Example::
>>> u = Zipcode.objects.unionagg() # This may take a long time.
>>> u = Zipcode.objects.filter(poly__within=bbox).unionagg() # A more sensible approach.
===================== =====================================================
Keyword Argument Description
===================== =====================================================
``tolerance`` This keyword is for Oracle only. It is for the
``tolerance`` This keyword is for Oracle only. It is for the
tolerance value used by the ``SDOAGGRTYPE``
procedure; the `Oracle documentation`__ has more
procedure; the `Oracle documentation`__ has more
details.
===================== =====================================================
__ http://download.oracle.com/docs/html/B14255_01/sdo_intro.htm#sthref150
__ http://download.oracle.com/docs/html/B14255_01/sdo_intro.htm#sthref150
Aggregate Functions
-------------------

204
docs/ref/contrib/gis/install.txt
View File

@@ -13,7 +13,7 @@ In general, GeoDjango installation requires:
3. :ref:`geospatial_libs`
Details for each of the requirements and installation instructions
are provided in the sections below. In addition, platform-specific
are provided in the sections below. In addition, platform-specific
instructions are available for:
* :ref:`macosx`
@@ -23,10 +23,10 @@ instructions are available for:
.. admonition:: Use the Source
Because GeoDjango takes advantage of the latest in the open source geospatial
software technology, recent versions of the libraries are necessary.
software technology, recent versions of the libraries are necessary.
If binary packages aren't available for your platform,
:ref:`installation from source <build_from_source>`
may be required. When compiling the libraries from source, please follow the
may be required. When compiling the libraries from source, please follow the
directions closely, especially if you're a beginner.
Requirements
@@ -37,8 +37,8 @@ Requirements
Python 2.4+
-----------
Because of heavy use of the decorator syntax, Python 2.4 is minimum
version supported by GeoDjango. Python 2.5+ is recommended because the
`ctypes`__ module comes included; otherwise, 2.4 users will need to
version supported by GeoDjango. Python 2.5+ is recommended because the
`ctypes`__ module comes included; otherwise, 2.4 users will need to
`download and install ctypes`__.
__ http://docs.python.org/lib/module-ctypes.html
@@ -50,18 +50,18 @@ Django
------
Because GeoDjango is included with Django, please refer to Django's
:ref:`installation instructions <intro-install>` for details on how to install.
:doc:`installation instructions </intro/install>` for details on how to install.
.. _spatial_database:
Spatial Database
----------------
PostgreSQL (with PostGIS), MySQL, Oracle, and SQLite (with SpatiaLite) are
PostgreSQL (with PostGIS), MySQL, Oracle, and SQLite (with SpatiaLite) are
the spatial databases currently supported.
.. note::
PostGIS is recommended, because it is the most mature and feature-rich
PostGIS is recommended, because it is the most mature and feature-rich
open source spatial database.
The geospatial libraries required for a GeoDjango installation depends
@@ -81,7 +81,7 @@ SQLite GEOS, GDAL, PROJ.4, SpatiaLite 3.6.+ Requires
Geospatial Libraries
--------------------
GeoDjango uses and/or provides interfaces for the the following open source
GeoDjango uses and/or provides interfaces for the the following open source
geospatial libraries:
======================== ==================================== ================================ ==========================
@@ -117,7 +117,7 @@ Building from Source
====================
When installing from source on UNIX and GNU/Linux systems, please follow
the installation instructions carefully, and install the libraries in the
the installation instructions carefully, and install the libraries in the
given order. If using MySQL or Oracle as the spatial database, only GEOS
is required.
@@ -147,13 +147,13 @@ internal geometry representation used by GeoDjango (it's behind the "lazy"
geometries). Specifically, the C API library is called (e.g., ``libgeos_c.so``)
directly from Python using ctypes.
First, download GEOS 3.2 from the refractions website and untar the source
First, download GEOS 3.2 from the refractions website and untar the source
archive::
$ wget http://download.osgeo.org/geos/geos-3.2.2.tar.bz2
$ tar xjf geos-3.2.2.tar.bz2
Next, change into the directory where GEOS was unpacked, run the configure
Next, change into the directory where GEOS was unpacked, run the configure
script, compile, and install::
$ cd geos-3.2.2
@@ -172,7 +172,7 @@ When GeoDjango can't find GEOS, this error is raised::
ImportError: Could not find the GEOS library (tried "geos_c"). Try setting GEOS_LIBRARY_PATH in your settings.
The most common solution is to properly configure your :ref:`libsettings` *or* set
The most common solution is to properly configure your :ref:`libsettings` *or* set
:ref:`geoslibrarypath` in your settings.
If using a binary package of GEOS (e.g., on Ubuntu 8.10), you may need to :ref:`binutils`.
@@ -191,7 +191,7 @@ C library. For example::
.. note::
The setting must be the *full* path to the **C** shared library; in
The setting must be the *full* path to the **C** shared library; in
other words you want to use ``libgeos_c.so``, not ``libgeos.so``.
.. _proj4:
@@ -199,7 +199,7 @@ C library. For example::
PROJ.4
------
`PROJ.4`_ is a library for converting geospatial data to different coordinate
`PROJ.4`_ is a library for converting geospatial data to different coordinate
reference systems.
First, download the PROJ.4 source code and datum shifting files [#]_::
@@ -228,12 +228,12 @@ PostGIS
-------
`PostGIS`__ adds geographic object support to PostgreSQL, turning it
into a spatial database. :ref:`geosbuild` and :ref:`proj4` should be
into a spatial database. :ref:`geosbuild` and :ref:`proj4` should be
installed prior to building PostGIS.
.. note::
The `psycopg2`_ module is required for use as the database adaptor
The `psycopg2`_ module is required for use as the database adaptor
when using GeoDjango with PostGIS.
.. _psycopg2: http://initd.org/projects/psycopg2
@@ -256,7 +256,7 @@ Finally, make and install::
.. note::
GeoDjango does not automatically create a spatial database. Please
GeoDjango does not automatically create a spatial database. Please
consult the section on :ref:`spatialdb_template` for more information.
__ http://postgis.refractions.net/
@@ -267,7 +267,7 @@ GDAL
----
`GDAL`__ is an excellent open source geospatial library that has support for
reading most vector and raster spatial data formats. Currently, GeoDjango only
reading most vector and raster spatial data formats. Currently, GeoDjango only
supports :ref:`GDAL's vector data <ref-gdal>` capabilities [#]_.
:ref:`geosbuild` and :ref:`proj4` should be installed prior to building GDAL.
@@ -287,11 +287,11 @@ Configure, make and install::
.. note::
Because GeoDjango has it's own Python interface, the preceding instructions
do not build GDAL's own Python bindings. The bindings may be built by
do not build GDAL's own Python bindings. The bindings may be built by
adding the ``--with-python`` flag when running ``configure``. See
`GDAL/OGR In Python`__ for more information on GDAL's bindings.
`GDAL/OGR In Python`__ for more information on GDAL's bindings.
If you have any problems, please see the troubleshooting section below for
If you have any problems, please see the troubleshooting section below for
suggestions and solutions.
__ http://trac.osgeo.org/gdal/
@@ -312,7 +312,7 @@ will be false::
>>> gdal.HAS_GDAL
False
The solution is to properly configure your :ref:`libsettings` *or* set
The solution is to properly configure your :ref:`libsettings` *or* set
:ref:`gdallibrarypath` in your settings.
.. _gdallibrarypath:
@@ -332,22 +332,22 @@ the GDAL library. For example::
Can't find GDAL data files (``GDAL_DATA``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When installed from source, GDAL versions 1.5.1 and below have an autoconf bug
that places data in the wrong location. [#]_ This can lead to error messages
When installed from source, GDAL versions 1.5.1 and below have an autoconf bug
that places data in the wrong location. [#]_ This can lead to error messages
like this::
ERROR 4: Unable to open EPSG support file gcs.csv.
...
OGRException: OGR failure.
The solution is to set the ``GDAL_DATA`` environment variable to the location of the
GDAL data files before invoking Python (typically ``/usr/local/share``; use
The solution is to set the ``GDAL_DATA`` environment variable to the location of the
GDAL data files before invoking Python (typically ``/usr/local/share``; use
``gdal-config --datadir`` to find out). For example::
$ export GDAL_DATA=`gdal-config --datadir`
$ python manage.py shell
If using Apache, you may need to add this environment variable to your configuration
If using Apache, you may need to add this environment variable to your configuration
file::
SetEnv GDAL_DATA /usr/local/share
@@ -363,13 +363,13 @@ SpatiaLite
Mac OS X users should follow the instructions in the :ref:`kyngchaos` section,
as it is much easier than building from source.
`SpatiaLite`__ adds spatial support to SQLite, turning it into a full-featured
`SpatiaLite`__ adds spatial support to SQLite, turning it into a full-featured
spatial database. Because SpatiaLite has special requirements, it typically
requires SQLite and pysqlite2 (the Python SQLite DB-API adaptor) to be built from
requires SQLite and pysqlite2 (the Python SQLite DB-API adaptor) to be built from
source. :ref:`geosbuild` and :ref:`proj4` should be installed prior to building
SpatiaLite.
After installation is complete, don't forget to read the post-installation
After installation is complete, don't forget to read the post-installation
docs on :ref:`create_spatialite_db`.
__ http://www.gaia-gis.it/spatialite/index.html
@@ -380,7 +380,7 @@ SQLite
^^^^^^
Typically, SQLite packages are not compiled to include the `R*Tree module`__ --
thus it must be compiled from source. First download the latest amalgamation
thus it must be compiled from source. First download the latest amalgamation
source archive from the `SQLite download page`__, and extract::
$ wget http://sqlite.org/sqlite-amalgamation-3.6.23.1.tar.gz
@@ -398,7 +398,7 @@ needs to be customized so that SQLite knows to build the R*Tree module::
.. note::
If using Ubuntu, installing a newer SQLite from source can be very difficult
because it links to the existing ``libsqlite3.so`` in ``/usr/lib`` which
because it links to the existing ``libsqlite3.so`` in ``/usr/lib`` which
many other packages depend on. Unfortunately, the best solution at this time
is to overwrite the existing library by adding ``--prefix=/usr`` to the
``configure`` command.
@@ -420,7 +420,7 @@ SpatiaLite library source and tools bundle from the `download page`__::
$ tar xzf spatialite-tools-2.3.1.tar.gz
Prior to attempting to build, please read the important notes below to see if
customization of the ``configure`` command is necessary. If not, then run the
customization of the ``configure`` command is necessary. If not, then run the
``configure`` script, make, and install for the SpatiaLite library::
$ cd libspatialite-amalgamation-2.3.1
@@ -431,7 +431,7 @@ customization of the ``configure`` command is necessary. If not, then run the
Finally, do the same for the SpatiaLite tools::
$ cd spatialite-tools-2.3.1
$ cd spatialite-tools-2.3.1
$ ./configure # May need to modified, see notes below.
$ make
$ sudo make install
@@ -440,15 +440,15 @@ Finally, do the same for the SpatiaLite tools::
.. note::
If you've installed GEOS and PROJ.4 from binary packages, you will have to specify
their paths when running the ``configure`` scripts for *both* the library and the
tools (the configure scripts look, by default, in ``/usr/local``). For example,
their paths when running the ``configure`` scripts for *both* the library and the
tools (the configure scripts look, by default, in ``/usr/local``). For example,
on Debian/Ubuntu distributions that have GEOS and PROJ.4 packages, the command would be::
$ ./configure --with-proj-include=/usr/include --with-proj-lib=/usr/lib --with-geos-include=/usr/include --with-geos-lib=/usr/lib
.. note::
For Mac OS X users building from source, the SpatiaLite library *and* tools
For Mac OS X users building from source, the SpatiaLite library *and* tools
need to have their ``target`` configured::
$ ./configure --target=macosx
@@ -463,7 +463,7 @@ pysqlite2
Because SpatiaLite must be loaded as an external extension, it requires the
``enable_load_extension`` method, which is only available in versions 2.5+.
Thus, download pysqlite2 2.6, and untar::
$ wget http://pysqlite.googlecode.com/files/pysqlite-2.6.0.tar.gz
$ tar xzf pysqlite-2.6.0.tar.gz
$ cd pysqlite-2.6.0
@@ -484,7 +484,7 @@ to look like the following::
``define=SQLITE_OMIT_LOAD_EXTENSION`` flag and that the ``include_dirs``
and ``library_dirs`` settings are uncommented and set to the appropriate
path if the SQLite header files and libraries are not in ``/usr/include``
and ``/usr/lib``, respectively.
and ``/usr/lib``, respectively.
After modifying ``setup.cfg`` appropriately, then run the ``setup.py`` script
to build and install::
@@ -500,7 +500,7 @@ Creating a Spatial Database Template for PostGIS
------------------------------------------------
Creating a spatial database with PostGIS is different than normal because
additional SQL must be loaded to enable spatial functionality. Because of
additional SQL must be loaded to enable spatial functionality. Because of
the steps in this process, it's better to create a database template that
can be reused later.
@@ -518,7 +518,7 @@ user. For example, you can use the following to become the ``postgres`` user::
version 1.5 uses ``<sharedir>/contrib/postgis-1.5/postgis.sql``.
The example below assumes PostGIS 1.5, thus you may need to modify
``POSTGIS_SQL_PATH`` and the name of the SQL file for the specific
``POSTGIS_SQL_PATH`` and the name of the SQL file for the specific
version of PostGIS you are using.
Once you're a database super user, then you may execute the following commands
@@ -598,7 +598,7 @@ __ http://www.gaia-gis.it/spatialite/resources.html
Add ``django.contrib.gis`` to ``INSTALLED_APPS``
------------------------------------------------
Like other Django contrib applications, you will *only* need to add
Like other Django contrib applications, you will *only* need to add
:mod:`django.contrib.gis` to :setting:`INSTALLED_APPS` in your settings.
This is the so that ``gis`` templates can be located -- if not done, then
features such as the geographic admin or KML sitemaps will not function properly.
@@ -630,7 +630,7 @@ Invoke the Django shell from your project and execute the
In Django 1.1 the name of this function is ``add_postgis_srs``.
This adds an entry for the 900913 SRID to the ``spatial_ref_sys`` (or equivalent)
table, making it possible for the spatial database to transform coordinates in
table, making it possible for the spatial database to transform coordinates in
this projection. You only need to execute this command *once* per spatial database.
Troubleshooting
@@ -640,8 +640,8 @@ If you can't find the solution to your problem here then participate in the
community! You can:
* Join the ``#geodjango`` IRC channel on FreeNode (may be accessed on the
web via `Mibbit`__). Please be patient and polite -- while you may not
get an immediate response, someone will attempt to answer your question
web via `Mibbit`__). Please be patient and polite -- while you may not
get an immediate response, someone will attempt to answer your question
as soon as they see it.
* Ask your question on the `GeoDjango`__ mailing list.
* File a ticket on the `Django trac`__ if you think there's a bug. Make
@@ -659,7 +659,7 @@ Library Environment Settings
By far, the most common problem when installing GeoDjango is that the
external shared libraries (e.g., for GEOS and GDAL) cannot be located. [#]_
Typically, the cause of this problem is that the operating system isn't aware
Typically, the cause of this problem is that the operating system isn't aware
of the directory where the libraries built from source were installed.
In general, the library path may be set on a per-user basis by setting
@@ -670,9 +670,9 @@ system.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A user may set this environment variable to customize the library paths
they want to use. The typical library directory for software
they want to use. The typical library directory for software
built from source is ``/usr/local/lib``. Thus, ``/usr/local/lib`` needs
to be included in the ``LD_LIBRARY_PATH`` variable. For example, the user
to be included in the ``LD_LIBRARY_PATH`` variable. For example, the user
could place the following in their bash profile::
export LD_LIBRARY_PATH=/usr/local/lib
@@ -682,7 +682,7 @@ Setting System Library Path
On GNU/Linux systems, there is typically a file in ``/etc/ld.so.conf``, which may include
additional paths from files in another directory, such as ``/etc/ld.so.conf.d``.
As the root user, add the custom library path (like ``/usr/local/lib``) on a
As the root user, add the custom library path (like ``/usr/local/lib``) on a
new line in ``ld.so.conf``. This is *one* example of how to do so::
$ sudo echo /usr/local/lib >> /etc/ld.so.conf
@@ -702,9 +702,9 @@ Install ``binutils``
GeoDjango uses the ``find_library`` function (from the ``ctypes.util`` Python
module) to discover libraries. The ``find_library`` routine uses a program
called ``objdump`` (part of the ``binutils`` package) to verify a shared
called ``objdump`` (part of the ``binutils`` package) to verify a shared
library on GNU/Linux systems. Thus, if ``binutils`` is not installed on your
Linux system then Python's ctypes may not be able to find your library even if
Linux system then Python's ctypes may not be able to find your library even if
your library path is set correctly and geospatial libraries were built perfectly.
The ``binutils`` package may be installed on Debian and Ubuntu systems using the
@@ -735,10 +735,10 @@ several different options for installing GeoDjango. These options are:
.. note::
Currently, the easiest and recommended approach for installing GeoDjango
on OS X is to use the KyngChaos packages.
on OS X is to use the KyngChaos packages.
This section also includes instructions for installing an upgraded version
of :ref:`macosx_python` from packages provided by the Python Software
This section also includes instructions for installing an upgraded version
of :ref:`macosx_python` from packages provided by the Python Software
Foundation, however, this is not required.
.. _macosx_python:
@@ -747,8 +747,8 @@ Python
^^^^^^
Although OS X comes with Python installed, users can use framework
installers (`2.5`__ and `2.6`__ are available) provided by
the Python Software Foundation. An advantage to using the installer is
installers (`2.5`__ and `2.6`__ are available) provided by
the Python Software Foundation. An advantage to using the installer is
that OS X's Python will remain "pristine" for internal operating system
use.
@@ -756,7 +756,7 @@ __ http://python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg
__ http://python.org/ftp/python/2.6.2/python-2.6.2-macosx2009-04-16.dmg
.. note::
You will need to modify the ``PATH`` environment variable in your
``.profile`` file so that the new version of Python is used when
``python`` is entered at the command-line::
@@ -768,15 +768,15 @@ __ http://python.org/ftp/python/2.6.2/python-2.6.2-macosx2009-04-16.dmg
KyngChaos Packages
^^^^^^^^^^^^^^^^^^
William Kyngesburye provides a number of `geospatial library binary packages`__
that make it simple to get GeoDjango installed on OS X without compiling
William Kyngesburye provides a number of `geospatial library binary packages`__
that make it simple to get GeoDjango installed on OS X without compiling
them from source. However, the `Apple Developer Tools`_ are still necessary
for compiling the Python database adapters :ref:`psycopg2_kyngchaos` (for PostGIS)
and :ref:`pysqlite2_kyngchaos` (for SpatiaLite).
and :ref:`pysqlite2_kyngchaos` (for SpatiaLite).
.. note::
SpatiaLite users should consult the :ref:`spatialite_kyngchaos` section
SpatiaLite users should consult the :ref:`spatialite_kyngchaos` section
after installing the packages for additional instructions.
Download the framework packages for:
@@ -834,7 +834,7 @@ described above, ``psycopg2`` may be installed using the following command::
pysqlite2
~~~~~~~~~
Follow the :ref:`pysqlite2` source install instructions, however,
Follow the :ref:`pysqlite2` source install instructions, however,
when editing the ``setup.cfg`` use the following instead::
[build_ext]
@@ -851,7 +851,7 @@ SpatiaLite
When :ref:`create_spatialite_db`, the ``spatialite`` program is required.
However, instead of attempting to compile the SpatiaLite tools from source,
download the `SpatiaLite Binaries`__ for OS X, and install ``spatialite`` in a
download the `SpatiaLite Binaries`__ for OS X, and install ``spatialite`` in a
location available in your ``PATH``. For example::
$ curl -O http://www.gaia-gis.it/spatialite/spatialite-tools-osx-x86-2.3.1.tar.gz
@@ -887,9 +887,9 @@ __ http://www.finkproject.org/
MacPorts
^^^^^^^^
`MacPorts`__ may be used to install GeoDjango prerequisites on Macintosh
`MacPorts`__ may be used to install GeoDjango prerequisites on Macintosh
computers running OS X. Because MacPorts still builds the software from source,
the `Apple Developer Tools`_ are required.
the `Apple Developer Tools`_ are required.
Summary::
@@ -898,7 +898,7 @@ Summary::
$ sudo port install proj
$ sudo port install postgis
$ sudo port install gdal
$ sudo port install libgeoip
$ sudo port install libgeoip
.. note::
@@ -929,9 +929,9 @@ Ubuntu
8.04 and lower
~~~~~~~~~~~~~~
The 8.04 (and lower) versions of Ubuntu use GEOS v2.2.3 in their binary packages,
which is incompatible with GeoDjango. Thus, do *not* use the binary packages
for GEOS or PostGIS and build some prerequisites from source, per the instructions
The 8.04 (and lower) versions of Ubuntu use GEOS v2.2.3 in their binary packages,
which is incompatible with GeoDjango. Thus, do *not* use the binary packages
for GEOS or PostGIS and build some prerequisites from source, per the instructions
in this document; however, it is okay to use the PostgreSQL binary packages.
For more details, please see the Debian instructions for :ref:`etch` below.
@@ -970,11 +970,11 @@ Optional packages to consider:
* ``python-gdal`` for GDAL's own Python bindings -- includes interfaces for raster manipulation
.. note::
The Ubuntu ``proj`` package does not come with the datum shifting files
installed, which will cause problems with the geographic admin because
installed, which will cause problems with the geographic admin because
the ``null`` datum grid is not available for transforming geometries to the
spherical mercator projection. A solution is to download the
spherical mercator projection. A solution is to download the
datum-shifting files, create the grid file, and install it yourself::
$ wget http://download.osgeo.org/proj/proj-datumgrid-1.4.tar.gz
@@ -985,7 +985,7 @@ Optional packages to consider:
$ sudo cp null /usr/share/proj
Otherwise, the Ubuntu ``proj`` package is fine for general use as long as you
do not plan on doing any database transformation of geometries to the
do not plan on doing any database transformation of geometries to the
Google projection (900913).
.. note::
@@ -1032,14 +1032,14 @@ Optional packages:
Source Packages
~~~~~~~~~~~~~~~
You will still have to install :ref:`geosbuild`, :ref:`proj4`,
:ref:`postgis`, and :ref:`gdalbuild` from source. Please follow the
:ref:`postgis`, and :ref:`gdalbuild` from source. Please follow the
directions carefully.
.. _lenny:
5.0 (Lenny)
^^^^^^^^^^^
This version is comparable to Ubuntu :ref:`ibex`, so the command
This version is comparable to Ubuntu :ref:`ibex`, so the command
is very similar::
$ sudo apt-get install binutils libgdal1-1.5.0 postgresql-8.3 postgresql-8.3-postgis postgresql-server-dev-8.3 python-psycopg2 python-setuptools
@@ -1086,13 +1086,13 @@ Python
^^^^^^
First, download the `Python 2.6 installer`__ from the Python website. Next,
execute the installer and use defaults, e.g., keep 'Install for all users'
execute the installer and use defaults, e.g., keep 'Install for all users'
checked and the installation path set as ``C:\Python26``.
.. note::
You may already have a version of Python installed in ``C:\python`` as ESRI
products sometimes install a copy there. *You should still install a
products sometimes install a copy there. *You should still install a
fresh version of Python 2.6.*
__ http://python.org/ftp/python/2.6.2/python-2.6.2.msi
@@ -1107,21 +1107,21 @@ the EnterpriseDB website.
PostgreSQL 8.3 is required because PostGIS is not available yet for 8.4.
After downloading, simply click on the installer, follow the
on-screen directions, and keep the default options (e.g., keep the installation
After downloading, simply click on the installer, follow the
on-screen directions, and keep the default options (e.g., keep the installation
path as ``C:\Program Files\PostgreSQL\8.3``).
.. note::
This PostgreSQL installation process will create both a new windows user to be the
'postgres service account' and a special 'postgres superuser' to own the database
cluster. You will be prompted to set a password for both users (make sure to write
them down!). To see basic details on the 'service user' account right click on
'My Computer' and select 'Manage' or go to: Control Panel -> Administrative Tools ->
This PostgreSQL installation process will create both a new windows user to be the
'postgres service account' and a special 'postgres superuser' to own the database
cluster. You will be prompted to set a password for both users (make sure to write
them down!). To see basic details on the 'service user' account right click on
'My Computer' and select 'Manage' or go to: Control Panel -> Administrative Tools ->
Computer Management -> System Tools -> Local Users and Groups.
If installed successfully, the PostgreSQL server will run in the background each time
the system as started as a Windows service. When finished, the installer should launch
If installed successfully, the PostgreSQL server will run in the background each time
the system as started as a Windows service. When finished, the installer should launch
the Application Stack Builder (ASB) -- use this to install PostGIS, see instructions
below for more details. A 'PostgreSQL 8.3' start menu group should be created that
contains shortcuts for the ASB and 'Command Prompt', which launches a terminal window
@@ -1132,22 +1132,22 @@ __ http://www.enterprisedb.com/products/pgdownload.do#windows
PostGIS
^^^^^^^
From the Application Stack Builder (Programs -> PostgreSQL 8.3), select
'PostgreSQL Database Server 8.3 on port 5432' from the drop down menu. Next,
From the Application Stack Builder (Programs -> PostgreSQL 8.3), select
'PostgreSQL Database Server 8.3 on port 5432' from the drop down menu. Next,
select 'PostGIS 1.3.6 for PostgreSQL 8.3' from the 'Spatial Extensions' tree
in the list. Select only the default options during install (do not uncheck
in the list. Select only the default options during install (do not uncheck
the option to create a default PostGIS database).
.. note::
You will be prompted to enter your 'postgres superuser' password in the
You will be prompted to enter your 'postgres superuser' password in the
'Database Connection Information' dialog.
psycopg2
^^^^^^^^
The ``psycopg2`` Python module provides the interface between Python and the
PostgreSQL database. Download the `Windows installer`__ (v2.0.10) and run
PostgreSQL database. Download the `Windows installer`__ (v2.0.10) and run
using the default settings. [#]_
__ http://www.stickpeople.com/projects/python/win-psycopg/psycopg2-2.0.10.win32-py2.6-pg8.3.7-release.exe
@@ -1160,31 +1160,31 @@ of the process for installing GeoDjango on Windows platforms. The installer
automatically installs Django 1.1, GDAL 1.6.0, PROJ 4.6.1 (including datum grid
files), and configures the necessary environment variables.
Once the installer has completed, log out and log back in so that the
Once the installer has completed, log out and log back in so that the
modifications to the system environment variables take effect, and you
should be good to go.
.. note::
The installer modifies the system ``Path`` environment variable to
include ``C:\Program Files\PostgreSQL\8.3\bin`` and
include ``C:\Program Files\PostgreSQL\8.3\bin`` and
``C:\Program Files\GeoDjango\bin``. This is required so that Python
may find the GEOS DLL provided by PostGIS and the GDAL DLL provided
by the installer. The installer also sets the ``GDAL_DATA`` and
by the installer. The installer also sets the ``GDAL_DATA`` and
``PROJ_LIB`` environment variables.
__ http://geodjango.org/windows/GeoDjango_Installer.exe
.. rubric:: Footnotes
.. [#] The datum shifting files are needed for converting data to and from certain projections.
For example, the PROJ.4 string for the `Google projection (900913) <http://spatialreference.org/ref/epsg/900913/proj4>`_
requires the ``null`` grid file only included in the extra datum shifting files.
For example, the PROJ.4 string for the `Google projection (900913) <http://spatialreference.org/ref/epsg/900913/proj4>`_
requires the ``null`` grid file only included in the extra datum shifting files.
It is easier to install the shifting files now, then to have debug a problem caused by their absence later.
.. [#] Specifically, GeoDjango provides support for the `OGR <http://gdal.org/ogr>`_ library, a component of GDAL.
.. [#] See `GDAL ticket #2382 <http://trac.osgeo.org/gdal/ticket/2382>`_.
.. [#] GeoDjango uses the `find_library <http://docs.python.org/library/ctypes.html#finding-shared-libraries>`_
routine from ``ctypes.util`` to locate shared libraries.
.. [#] The ``psycopg2`` Windows installers are packaged and maintained by
`Jason Erickson <http://www.stickpeople.com/projects/python/win-psycopg/>`_.
.. [#] The source code for the installer is available in the `nsis_installer <http://geodjango.org/hg/nsis_installer/>`_
routine from ``ctypes.util`` to locate shared libraries.
.. [#] The ``psycopg2`` Windows installers are packaged and maintained by
`Jason Erickson <http://www.stickpeople.com/projects/python/win-psycopg/>`_.
.. [#] The source code for the installer is available in the `nsis_installer <http://geodjango.org/hg/nsis_installer/>`_
GeoDjango mercurial repository.

92
docs/ref/contrib/gis/layermapping.txt
View File

@@ -14,7 +14,7 @@ vector spatial data files (e.g. shapefiles) intoto GeoDjango models.
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
a vector layer, converting to another coordinate system (e.g. WGS84), and
then inserting into a GeoDjango model.
.. note::
@@ -27,7 +27,7 @@ then inserting into a GeoDjango model.
that :class:`LayerMapping` is using too much memory, set
:setting:`DEBUG` to ``False`` in your settings. When :setting:`DEBUG`
is set to ``True``, Django :ref:`automatically logs <faq-see-raw-sql-queries>`
*every* SQL query -- thus, when SQL statements contain geometries, it is
*every* SQL query -- thus, when SQL statements contain geometries, it is
easy to consume more memory than is typical.
Example
@@ -50,7 +50,7 @@ Example
DATUM["WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]]
UNIT["Degree",0.017453292519943295]]
2. Now we define our corresponding Django model (make sure to use ``syncdb``)::
@@ -71,16 +71,16 @@ Example
>>> mapping = {'name' : 'str', # The 'name' model field maps to the 'str' layer field.
'poly' : 'POLYGON', # For geometry fields use OGC name.
} # The mapping is a dictionary
>>> lm = LayerMapping(TestGeo, 'test_poly.shp', mapping)
>>> lm.save(verbose=True) # Save the layermap, imports the data.
>>> lm = LayerMapping(TestGeo, 'test_poly.shp', mapping)
>>> lm.save(verbose=True) # Save the layermap, imports the data.
Saved: Name: 1
Saved: Name: 2
Saved: Name: 3
Here, :class:`LayerMapping` just 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
reference system of the GeoDjango model (NAD83). If no spatial reference
system is defined for the layer, use the ``source_srs`` keyword with a
:class:`~django.contrib.gis.gdal.SpatialReference` object to specify one.
``LayerMapping`` API
@@ -106,43 +106,43 @@ Argument Description
model field is a geographic then it should
correspond to the OGR geometry type,
e.g., ``'POINT'``, ``'LINESTRING'``, ``'POLYGON'``.
================= =========================================================
================= =========================================================
===================== =====================================================
Keyword Arguments
===================== =====================================================
``layer`` The index of the layer to use from the Data Source
===================== =====================================================
``layer`` The index of the layer to use from the Data Source
(defaults to 0)
``source_srs`` Use this to specify the source SRS manually (for
example, some shapefiles don't come with a '.prj'
file). An integer SRID, WKT or PROJ.4 strings, and
:class:`django.contrib.gis.gdal.SpatialReference`
``source_srs`` Use this to specify the source SRS manually (for
example, some shapefiles don't come with a '.prj'
file). An integer SRID, WKT or PROJ.4 strings, and
:class:`django.contrib.gis.gdal.SpatialReference`
objects are accepted.
``encoding`` Specifies the character set encoding of the strings
in the OGR data source. For example, ``'latin-1'``,
``'utf-8'``, and ``'cp437'`` are all valid encoding
``encoding`` Specifies the character set encoding of the strings
in the OGR data source. For example, ``'latin-1'``,
``'utf-8'``, and ``'cp437'`` are all valid encoding
parameters.
``transaction_mode`` May be ``'commit_on_success'`` (default) or
``transaction_mode`` May be ``'commit_on_success'`` (default) or
``'autocommit'``.
``transform`` Setting this to False will disable coordinate
``transform`` Setting this to False will disable coordinate
transformations. In other words, geometries will
be inserted into the database unmodified from their
original state in the data source.
``unique`` Setting this to the name, or a tuple of names,
from the given model will create models unique
only to the given name(s). Geometries will from
each feature will be added into the collection
associated with the unique model. Forces
only to the given name(s). Geometries will from
each feature will be added into the collection
associated with the unique model. Forces
the transaction mode to be ``'autocommit'``.
``using`` New in version 1.2. Sets the database to use when
importing spatial data. Default is ``'default'``
===================== =====================================================
===================== =====================================================
``save()`` Keyword Arguments
----------------------------
@@ -156,42 +156,42 @@ specific feature ranges.
=========================== =================================================
Save Keyword Arguments Description
=========================== =================================================
``fid_range`` May be set with a slice or tuple of
(begin, end) feature ID's to map from
``fid_range`` May be set with a slice or tuple of
(begin, end) feature ID's to map from
the data source. In other words, this
keyword enables the user to selectively
keyword enables the user to selectively
import a subset range of features in the
geographic data source.
``progress`` When this keyword is set, status information
will be printed giving the number of features
processed and successfully saved. By default,
will be printed giving the number of features
processed and successfully saved. By default,
progress information will be printed every 1000
features processed, however, this default may
be overridden by setting this keyword with an
features processed, however, this default may
be overridden by setting this keyword with an
integer for the desired interval.
``silent`` By default, non-fatal error notifications are
printed to ``sys.stdout``, but this keyword may
``silent`` By default, non-fatal error notifications are
printed to ``sys.stdout``, but this keyword may
be set to disable these notifications.
``step`` If set with an integer, transactions will
occur at every step interval. For example, if
``step=1000``, a commit would occur after the
``step`` If set with an integer, transactions will
occur at every step interval. For example, if
``step=1000``, a commit would occur after the
1,000th feature, the 2,000th feature etc.
``stream`` Status information will be written to this file
handle. Defaults to using ``sys.stdout``, but
``stream`` Status information will be written to this file
handle. Defaults to using ``sys.stdout``, but
any object with a ``write`` method is supported.
``strict`` Execution of the model mapping will cease upon
``strict`` Execution of the model mapping will cease upon
the first error encountered. The default value
(``False``)
behavior is to attempt to continue.
``verbose`` If set, information will be printed
subsequent to each model save
``verbose`` If set, information will be printed
subsequent to each model save
executed on the database.
=========================== =================================================
@@ -213,7 +213,7 @@ If you encounter the following error when using ``LayerMapping`` and MySQL::
OperationalError: (1153, "Got a packet bigger than 'max_allowed_packet' bytes")
Then the solution is to increase the value of the ``max_allowed_packet``
setting in your MySQL configuration. For example, the default value may
setting in your MySQL configuration. For example, the default value may
be something low like one megabyte -- the setting may be modified in MySQL's
configuration file (``my.cnf``) in the ``[mysqld]`` section::

22
docs/ref/contrib/gis/measure.txt
View File

@@ -7,17 +7,17 @@ Measurement Objects
.. module:: django.contrib.gis.measure
:synopsis: GeoDjango's distance and area measurment objects.
The :mod:`django.contrib.gis.measure` module contains objects that allow
for convenient representation of distance and area units of measure. [#]_
Specifically, it implements two objects, :class:`Distance` and
:class:`Area` -- both of which may be accessed via the
The :mod:`django.contrib.gis.measure` module contains objects that allow
for convenient representation of distance and area units of measure. [#]_
Specifically, it implements two objects, :class:`Distance` and
:class:`Area` -- both of which may be accessed via the
:class:`D` and :class:`A` convenience aliases, respectively.
Example
=======
:class:`Distance` objects may be instantiated using a keyword argument indicating the
context of the units. In the example below, two different distance objects are
:class:`Distance` objects may be instantiated using a keyword argument indicating the
context of the units. In the example below, two different distance objects are
instantiated in units of kilometers (``km``) and miles (``mi``)::
>>> from django.contrib.gis.measure import Distance, D
@@ -40,7 +40,7 @@ Moreover, arithmetic operations may be performed between the distance
objects::
>>> print d1 + d2 # Adding 5 miles to 5 kilometers
13.04672 km
13.04672 km
>>> print d2 - d1 # Subtracting 5 kilometers from 5 miles
1.89314403881 mi
@@ -67,7 +67,7 @@ Supported units
================================= ========================================
Unit Attribute Full name or alias(es)
================================= ========================================
``km`` Kilometre, Kilometer
``km`` Kilometre, Kilometer
``mi`` Mile
``m`` Meter, Metre
``yd`` Yard
@@ -163,7 +163,7 @@ Measurement API
12.949940551680001
.. classmethod:: unit_attname(unit_name)
Returns the area unit attribute name for the given full unit name.
For example::
@@ -175,6 +175,6 @@ Measurement API
Alias for :class:`Area` class.
.. rubric:: Footnotes
.. [#] `Robert Coup <http://koordinates.com/>`_ is the initial author of the measure objects,
and was inspired by Brian Beck's work in `geopy <http://code.google.com/p/geopy/>`_
.. [#] `Robert Coup <http://koordinates.com/>`_ is the initial author of the measure objects,
and was inspired by Brian Beck's work in `geopy <http://code.google.com/p/geopy/>`_
and Geoff Biggs' PhD work on dimensioned units for robotics.

40
docs/ref/contrib/gis/model-api.txt
View File

@@ -8,11 +8,11 @@ GeoDjango Model API
:synopsis: GeoDjango model and field API.
This document explores the details of the GeoDjango Model API. Throughout this
section, we'll be using the following geographic model of a `ZIP code`__ as our
section, we'll be using the following geographic model of a `ZIP code`__ as our
example::
from django.contrib.gis.db import models
class Zipcode(models.Model):
code = models.CharField(max_length=5)
poly = models.PolygonField()
@@ -23,7 +23,7 @@ __ http://en.wikipedia.org/wiki/ZIP_code
Geometry Field Types
====================
Each of the following geometry field types correspond with the
Each of the following geometry field types correspond with the
OpenGIS Simple Features specification [#fnogc]_.
``GeometryField``
@@ -92,7 +92,7 @@ Selecting an SRID
^^^^^^^^^^^^^^^^^
Choosing an appropriate SRID for your model is an important decision that the
developer should consider carefully. The SRID is an integer specifier that
developer should consider carefully. The SRID is an integer specifier that
corresponds to the projection system that will be used to interpret the data
in the spatial database. [#fnsrid]_ Projection systems give the context to the
coordinates that specify a location. Although the details of `geodesy`__ are
@@ -105,7 +105,7 @@ location on the earth's surface. However, latitude and longitude are angles,
not distances. [#fnharvard]_ In other words, while the shortest path between two points on
a flat surface is a straight line, the shortest path between two points on a curved
surface (such as the earth) is an *arc* of a `great circle`__. [#fnthematic]_ Thus,
additional computation is required to obtain distances in planar units (e.g.,
additional computation is required to obtain distances in planar units (e.g.,
kilometers and miles). Using a geographic coordinate system may introduce
complications for the developer later on. For example, PostGIS versions 1.4
and below do not have the capability to perform distance calculations between
@@ -113,12 +113,12 @@ non-point geometries using geographic coordinate systems, e.g., constructing a
query to find all points within 5 miles of a county boundary stored as WGS84.
[#fndist]_
Portions of the earth's surface may projected onto a two-dimensional, or
Portions of the earth's surface may projected onto a two-dimensional, or
Cartesian, plane. Projected coordinate systems are especially convenient
for region-specific applications, e.g., if you know that your database will
only cover geometries in `North Kansas`__, then you may consider using projection
system specific to that region. Moreover, projected coordinate systems are
defined in Cartesian units (such as meters or feet), easing distance
only cover geometries in `North Kansas`__, then you may consider using projection
system specific to that region. Moreover, projected coordinate systems are
defined in Cartesian units (such as meters or feet), easing distance
calculations.
.. note::
@@ -131,7 +131,7 @@ calculations.
Additional Resources:
* `spatialreference.org`__: A Django-powered database of spatial reference
* `spatialreference.org`__: A Django-powered database of spatial reference
systems.
* `The State Plane Coordinate System`__: A website covering the various
projection systems used in the United States. Much of the U.S. spatial
@@ -150,7 +150,7 @@ __ http://welcome.warnercnr.colostate.edu/class_info/nr502/lg3/datums_coordinate
.. attribute:: GeometryField.spatial_index
Defaults to ``True``. Creates a spatial index for the given geometry
field.
field.
.. note::
@@ -185,7 +185,7 @@ three-dimensonal support.
.. attribute:: GeometryField.geography
If set to ``True``, this option will create a database column of
type geography, rather than geometry. Please refer to the
type geography, rather than geometry. Please refer to the
:ref:`geography type <geography-type>` section below for more
details.
@@ -212,7 +212,7 @@ to degrees if called on a geometry column in WGS84).
Because geography calculations involve more mathematics, only a subset of the
PostGIS spatial lookups are available for the geography type. Practically,
this means that in addition to the :ref:`distance lookups <distance-lookups>`
only the following additional :ref:`spatial lookups <spatial-lookups>` are
only the following additional :ref:`spatial lookups <spatial-lookups>` are
available for geography columns:
* :lookup:`bboverlaps`
@@ -231,13 +231,13 @@ determining `when to use geography data type over geometry data type
.. currentmodule:: django.contrib.gis.db.models
.. class:: GeoManager
In order to conduct geographic queries, each geographic model requires
In order to conduct geographic queries, each geographic model requires
a ``GeoManager`` model manager. This manager allows for the proper SQL
construction for geographic queries; thus, without it, all geographic filters
construction for geographic queries; thus, without it, all geographic filters
will fail. It should also be noted that ``GeoManager`` is required even if the
model does not have a geographic field itself, e.g., in the case of a
``ForeignKey`` relation to a model with a geographic field. For example,
if we had an ``Address`` model with a ``ForeignKey`` to our ``Zipcode``
model does not have a geographic field itself, e.g., in the case of a
``ForeignKey`` relation to a model with a geographic field. For example,
if we had an ``Address`` model with a ``ForeignKey`` to our ``Zipcode``
model::
from django.contrib.gis.db import models
@@ -251,7 +251,7 @@ model::
zipcode = models.ForeignKey(Zipcode)
objects = models.GeoManager()
The geographic manager is needed to do spatial queries on related ``Zipcode`` objects,
The geographic manager is needed to do spatial queries on related ``Zipcode`` objects,
for example::
qs = Address.objects.filter(zipcode__poly__contains='POINT(-104.590948 38.319914)')
@@ -260,7 +260,7 @@ for example::
.. [#fnogc] OpenGIS Consortium, Inc., `Simple Feature Specification For SQL <http://www.opengis.org/docs/99-049.pdf>`_, Document 99-049 (May 5, 1999).
.. [#fnogcsrid] *See id.* at Ch. 2.3.8, p. 39 (Geometry Values and Spatial Reference Systems).
.. [#fnsrid] Typically, SRID integer corresponds to an EPSG (`European Petroleum Survey Group <http://www.epsg.org>`_) identifier. However, it may also be associated with custom projections defined in spatial database's spatial reference systems table.
.. [#fnharvard] Harvard Graduate School of Design, `An Overview of Geodesy and Geographic Referencing Systems <http://www.gsd.harvard.edu/gis/manual/projections/fundamentals/>`_. This is an excellent resource for an overview of principles relating to geographic and Cartesian coordinate systems.
.. [#fnharvard] Harvard Graduate School of Design, `An Overview of Geodesy and Geographic Referencing Systems <http://www.gsd.harvard.edu/gis/manual/projections/fundamentals/>`_. This is an excellent resource for an overview of principles relating to geographic and Cartesian coordinate systems.
.. [#fnthematic] Terry A. Slocum, Robert B. McMaster, Fritz C. Kessler, & Hugh H. Howard, *Thematic Cartography and Geographic Visualization* (Prentice Hall, 2nd edition), at Ch. 7.1.3.
.. [#fndist] This limitation does not apply to PostGIS 1.5. It should be noted that even in previous versions of PostGIS, this isn't impossible using GeoDjango; you could for example, take a known point in a projected coordinate system, buffer it to the appropriate radius, and then perform an intersection operation with the buffer transformed to the geographic coordinate system.
.. [#fngeography] Please refer to the `PostGIS Geography Type <http://postgis.refractions.net/documentation/manual-1.5/ch04.html#PostGIS_Geography>`_ documentation for more details.

2
docs/ref/contrib/gis/testing.txt
View File

@@ -6,7 +6,7 @@ Testing GeoDjango Apps
In Django 1.2, the addition of :ref:`spatial-backends`
simplified the process of testing GeoDjango applications. Specifically, testing
GeoDjango applications is now the same as :ref:`topics-testing`.
GeoDjango applications is now the same as :doc:`/topics/testing`.
Included in this documentation are some additional notes and settings
for :ref:`testing-postgis` and :ref:`testing-spatialite` users.

106
docs/ref/contrib/gis/tutorial.txt
View File

@@ -15,8 +15,8 @@ geographic web applications, like location-based services. Some features includ
data formats.
* Editing of geometry fields inside the admin.
This tutorial assumes a familiarity with Django; thus, if you're brand new to
Django please read through the :ref:`regular tutorial <intro-tutorial01>` to introduce
This tutorial assumes a familiarity with Django; thus, if you're brand new to
Django please read through the :doc:`regular tutorial </intro/tutorial01>` to introduce
yourself with basic Django concepts.
.. note::
@@ -27,12 +27,12 @@ yourself with basic Django concepts.
This tutorial is going to guide you through guide the user through the creation
of a geographic web application for viewing the `world borders`_. [#]_ Some of
the code used in this tutorial is taken from and/or inspired by the
the code used in this tutorial is taken from and/or inspired by the
`GeoDjango basic apps`_ project. [#]_
.. note::
Proceed through the tutorial sections sequentially for step-by-step
Proceed through the tutorial sections sequentially for step-by-step
instructions.
.. _OGC: http://www.opengeospatial.org/
@@ -51,11 +51,11 @@ Create a Spatial Database
are already built into the database.
First, a spatial database needs to be created for our project. If using
PostgreSQL and PostGIS, then the following commands will
PostgreSQL and PostGIS, then the following commands will
create the database from a :ref:`spatial database template <spatialdb_template>`::
$ createdb -T template_postgis geodjango
.. note::
This command must be issued by a database user that has permissions to
@@ -65,9 +65,9 @@ create the database from a :ref:`spatial database template <spatialdb_template>`
$ sudo su - postgres
$ createuser --createdb geo
$ exit
Replace ``geo`` to correspond to the system login user name will be
connecting to the database. For example, ``johndoe`` if that is the
connecting to the database. For example, ``johndoe`` if that is the
system user that will be running GeoDjango.
Users of SQLite and SpatiaLite should consult the instructions on how
@@ -92,7 +92,7 @@ Configure ``settings.py``
The ``geodjango`` project settings are stored in the ``settings.py`` file. Edit
the database connection settings appropriately::
DATABASES = {
DATABASES = {
'default': {
'ENGINE': 'django.contrib.gis.db.backends.postgis',
'NAME': 'geodjango',
@@ -104,7 +104,7 @@ the database connection settings appropriately::
These database settings are for Django 1.2 and above.
In addition, modify the :setting:`INSTALLED_APPS` setting to include
In addition, modify the :setting:`INSTALLED_APPS` setting to include
:mod:`django.contrib.admin`, :mod:`django.contrib.gis`,
and ``world`` (our newly created application)::
@@ -142,8 +142,8 @@ unzipped the world borders data set includes files with the following extensions
* ``.shp``: Holds the vector data for the world borders geometries.
* ``.shx``: Spatial index file for geometries stored in the ``.shp``.
* ``.dbf``: Database file for holding non-geometric attribute data
(e.g., integer and character fields).
* ``.dbf``: Database file for holding non-geometric attribute data
(e.g., integer and character fields).
* ``.prj``: Contains the spatial reference information for the geographic
data stored in the shapefile.
@@ -153,7 +153,7 @@ __ http://en.wikipedia.org/wiki/Shapefile
Use ``ogrinfo`` to examine spatial data
---------------------------------------
The GDAL ``ogrinfo`` utility is excellent for examining metadata about
The GDAL ``ogrinfo`` utility is excellent for examining metadata about
shapefiles (or other vector data sources)::
$ ogrinfo world/data/TM_WORLD_BORDERS-0.3.shp
@@ -192,13 +192,13 @@ and use the ``-so`` option to get only important summary information::
LAT: Real (7.3)
This detailed summary information tells us the number of features in the layer
(246), the geographical extent, the spatial reference system ("SRS WKT"),
(246), the geographical extent, the spatial reference system ("SRS WKT"),
as well as detailed information for each attribute field. For example,
``FIPS: String (2.0)`` indicates that there's a ``FIPS`` character field
with a maximum length of 2; similarly, ``LON: Real (8.3)`` is a floating-point
field that holds a maximum of 8 digits up to three decimal places. Although
this information may be found right on the `world borders`_ website, this shows
you how to determine this information yourself when such metadata is not
you how to determine this information yourself when such metadata is not
provided.
Geographic Models
@@ -213,7 +213,7 @@ create a GeoDjango model to represent this data::
from django.contrib.gis.db import models
class WorldBorders(models.Model):
# Regular Django fields corresponding to the attributes in the
# Regular Django fields corresponding to the attributes in the
# world borders shapefile.
name = models.CharField(max_length=50)
area = models.IntegerField()
@@ -227,7 +227,7 @@ create a GeoDjango model to represent this data::
lon = models.FloatField()
lat = models.FloatField()
# GeoDjango-specific: a geometry field (MultiPolygonField), and
# GeoDjango-specific: a geometry field (MultiPolygonField), and
# overriding the default manager with a GeoManager instance.
mpoly = models.MultiPolygonField()
objects = models.GeoManager()
@@ -235,23 +235,23 @@ create a GeoDjango model to represent this data::
# So the model is pluralized correctly in the admin.
class Meta:
verbose_name_plural = "World Borders"
# Returns the string representation of the model.
# Returns the string representation of the model.
def __unicode__(self):
return self.name
Two important things to note:
1. The ``models`` module is imported from :mod:`django.contrib.gis.db`.
2. The model overrides its default manager with
2. The model overrides its default manager with
:class:`~django.contrib.gis.db.models.GeoManager`; this is *required*
to perform spatial queries.
to perform spatial queries.
When declaring a geometry field on your model the default spatial reference system
is WGS84 (meaning the `SRID`__ is 4326) -- in other words, the field coordinates are in
longitude/latitude pairs in units of degrees. If you want the coordinate system to be
different, then SRID of the geometry field may be customized by setting the ``srid``
with an integer corresponding to the coordinate system of your choice.
with an integer corresponding to the coordinate system of your choice.
__ http://en.wikipedia.org/wiki/SRID
@@ -259,7 +259,7 @@ Run ``syncdb``
--------------
After you've defined your model, it needs to be synced with the spatial database.
First, let's look at the SQL that will generate the table for the ``WorldBorders``
First, let's look at the SQL that will generate the table for the ``WorldBorders``
model::
$ python manage.py sqlall world
@@ -295,7 +295,7 @@ If satisfied, you may then create this table in the database by running the
Installing custom SQL for world.WorldBorders model
The ``syncdb`` command may also prompt you to create an admin user; go ahead and
do so (not required now, may be done at any point in the future using the
do so (not required now, may be done at any point in the future using the
``createsuperuser`` management command).
Importing Spatial Data
@@ -303,11 +303,11 @@ Importing Spatial Data
This section will show you how to take the data from the world borders
shapefile and import it into GeoDjango models using the :ref:`ref-layermapping`.
There are many different different ways to import data in to a
There are many different different ways to import data in to a
spatial database -- besides the tools included within GeoDjango, you
may also use the following to populate your spatial database:
* `ogr2ogr`_: Command-line utility, included with GDAL, that
* `ogr2ogr`_: Command-line utility, included with GDAL, that
supports loading a multitude of vector data formats into
the PostGIS, MySQL, and Oracle spatial databases.
* `shp2pgsql`_: This utility is included with PostGIS and only supports
@@ -339,7 +339,7 @@ tutorial, then we can determine the path using Python's built-in
>>> world_shp = os.path.abspath(os.path.join(os.path.dirname(world.__file__),
... 'data/TM_WORLD_BORDERS-0.3.shp'))
Now, the world borders shapefile may be opened using GeoDjango's
Now, the world borders shapefile may be opened using GeoDjango's
:class:`~django.contrib.gis.gdal.DataSource` interface::
>>> from django.contrib.gis.gdal import *
@@ -347,7 +347,7 @@ Now, the world borders shapefile may be opened using GeoDjango's
>>> print ds
/ ... /geodjango/world/data/TM_WORLD_BORDERS-0.3.shp (ESRI Shapefile)
Data source objects can have different layers of geospatial features; however,
Data source objects can have different layers of geospatial features; however,
shapefiles are only allowed to have one layer::
>>> print len(ds)
@@ -367,10 +367,10 @@ contains::
.. note::
Unfortunately the shapefile data format does not allow for greater
specificity with regards to geometry types. This shapefile, like
specificity with regards to geometry types. This shapefile, like
many others, actually includes ``MultiPolygon`` geometries in its
features. You need to watch out for this when creating your models
as a GeoDjango ``PolygonField`` will not accept a ``MultiPolygon``
as a GeoDjango ``PolygonField`` will not accept a ``MultiPolygon``
type geometry -- thus a ``MultiPolygonField`` is used in our model's
definition instead.
@@ -391,7 +391,7 @@ system associated with it -- if it does, the ``srs`` attribute will return a
Here we've noticed that the shapefile is in the popular WGS84 spatial reference
system -- in other words, the data uses units of degrees longitude and latitude.
In addition, shapefiles also support attribute fields that may contain
In addition, shapefiles also support attribute fields that may contain
additional data. Here are the fields on the World Borders layer:
>>> print lyr.fields
@@ -403,8 +403,8 @@ a string) associated with each of the fields:
>>> [fld.__name__ for fld in lyr.field_types]
['OFTString', 'OFTString', 'OFTString', 'OFTInteger', 'OFTString', 'OFTInteger', 'OFTInteger', 'OFTInteger', 'OFTInteger', 'OFTReal', 'OFTReal']
You can iterate over each feature in the layer and extract information from both
the feature's geometry (accessed via the ``geom`` attribute) as well as the
You can iterate over each feature in the layer and extract information from both
the feature's geometry (accessed via the ``geom`` attribute) as well as the
feature's attribute fields (whose **values** are accessed via ``get()``
method)::
@@ -427,7 +427,7 @@ And individual features may be retrieved by their feature ID::
>>> print feat.get('NAME')
San Marino
Here the boundary geometry for San Marino is extracted and looking
Here the boundary geometry for San Marino is extracted and looking
exported to WKT and GeoJSON::
>>> geom = feat.geom
@@ -465,7 +465,7 @@ We're going to dive right in -- create a file called ``load.py`` inside the
world_shp = os.path.abspath(os.path.join(os.path.dirname(__file__), 'data/TM_WORLD_BORDERS-0.3.shp'))
def run(verbose=True):
lm = LayerMapping(WorldBorders, world_shp, world_mapping,
lm = LayerMapping(WorldBorders, world_shp, world_mapping,
transform=False, encoding='iso-8859-1')
lm.save(strict=True, verbose=verbose)
@@ -473,8 +473,8 @@ We're going to dive right in -- create a file called ``load.py`` inside the
A few notes about what's going on:
* Each key in the ``world_mapping`` dictionary corresponds to a field in the
``WorldBorders`` model, and the value is the name of the shapefile field
that data will be loaded from.
``WorldBorders`` model, and the value is the name of the shapefile field
that data will be loaded from.
* The key ``mpoly`` for the geometry field is ``MULTIPOLYGON``, the
geometry type we wish to import as. Even if simple polygons are encountered
in the shapefile they will automatically be converted into collections prior
@@ -503,10 +503,10 @@ do the work::
Try ``ogrinspect``
------------------
Now that you've seen how to define geographic models and import data with the
Now that you've seen how to define geographic models and import data with the
:ref:`ref-layermapping`, it's possible to further automate this process with
use of the :djadmin:`ogrinspect` management command. The :djadmin:`ogrinspect`
command introspects a GDAL-supported vector data source (e.g., a shapefile) and
command introspects a GDAL-supported vector data source (e.g., a shapefile) and
generates a model definition and ``LayerMapping`` dictionary automatically.
The general usage of the command goes as follows::
@@ -525,13 +525,13 @@ and mapping dictionary created above, automatically::
A few notes about the command-line options given above:
* The ``--srid=4326`` option sets the SRID for the geographic field.
* The ``--mapping`` option tells ``ogrinspect`` to also generate a
* The ``--mapping`` option tells ``ogrinspect`` to also generate a
mapping dictionary for use with :class:`~django.contrib.gis.utils.LayerMapping`.
* The ``--multi`` option is specified so that the geographic field is a
:class:`~django.contrib.gis.db.models.MultiPolygonField` instead of just a
:class:`~django.contrib.gis.db.models.PolygonField`.
The command produces the following output, which may be copied
The command produces the following output, which may be copied
directly into the ``models.py`` of a GeoDjango application::
# This is an auto-generated Django model module created by ogrinspect.
@@ -584,7 +584,7 @@ Now, define a point of interest [#]_::
>>> pnt_wkt = 'POINT(-95.3385 29.7245)'
The ``pnt_wkt`` string represents the point at -95.3385 degrees longitude,
and 29.7245 degrees latitude. The geometry is in a format known as
and 29.7245 degrees latitude. The geometry is in a format known as
Well Known Text (WKT), an open standard issued by the Open Geospatial
Consortium (OGC). [#]_ Import the ``WorldBorders`` model, and perform
a ``contains`` lookup using the ``pnt_wkt`` as the parameter::
@@ -611,7 +611,7 @@ available -- the :ref:`ref-gis-db-api` documentation has more.
Automatic Spatial Transformations
---------------------------------
When querying the spatial database GeoDjango automatically transforms
When querying the spatial database GeoDjango automatically transforms
geometries if they're in a different coordinate system. In the following
example, the coordinate will be expressed in terms of `EPSG SRID 32140`__,
a coordinate system specific to south Texas **only** and in units of
@@ -634,26 +634,26 @@ of abstraction::
('SELECT "world_worldborders"."id", "world_worldborders"."name", "world_worldborders"."area",
"world_worldborders"."pop2005", "world_worldborders"."fips", "world_worldborders"."iso2",
"world_worldborders"."iso3", "world_worldborders"."un", "world_worldborders"."region",
"world_worldborders"."subregion", "world_worldborders"."lon", "world_worldborders"."lat",
"world_worldborders"."mpoly" FROM "world_worldborders"
"world_worldborders"."subregion", "world_worldborders"."lon", "world_worldborders"."lat",
"world_worldborders"."mpoly" FROM "world_worldborders"
WHERE ST_Intersects("world_worldborders"."mpoly", ST_Transform(%s, 4326))',
(<django.contrib.gis.db.backend.postgis.adaptor.PostGISAdaptor object at 0x25641b0>,))
>>> qs # printing evaluates the queryset
[<WorldBorders: United States>]
[<WorldBorders: United States>]
__ http://spatialreference.org/ref/epsg/32140/
Lazy Geometries
---------------
Geometries come to GeoDjango in a standardized textual representation. Upon
access of the geometry field, GeoDjango creates a `GEOS geometry object <ref-geos>`,
exposing powerful functionality, such as serialization properties for
access of the geometry field, GeoDjango creates a `GEOS geometry object <ref-geos>`,
exposing powerful functionality, such as serialization properties for
popular geospatial formats::
>>> sm = WorldBorders.objects.get(name='San Marino')
>>> sm.mpoly
<MultiPolygon object at 0x24c6798>
>>> sm.mpoly.wkt # WKT
>>> sm.mpoly.wkt # WKT
MULTIPOLYGON (((12.4157980000000006 43.9579540000000009, 12.4505540000000003 43.9797209999999978, ...
>>> sm.mpoly.wkb # WKB (as Python binary buffer)
<read-only buffer for 0x1fe2c70, size -1, offset 0 at 0x2564c40>
@@ -682,16 +682,16 @@ Google
Geographic Admin
----------------
GeoDjango extends :ref:`Django's admin application <ref-contrib-admin>` to
enable support for editing geometry fields.
GeoDjango extends :doc:`Django's admin application </ref/contrib/admin/index>`
to enable support for editing geometry fields.
Basics
^^^^^^
GeoDjango also supplements the Django admin by allowing users to create
GeoDjango also supplements the Django admin by allowing users to create
and modify geometries on a JavaScript slippy map (powered by `OpenLayers`_).
Let's dive in again -- create a file called ``admin.py`` inside the
Let's dive in again -- create a file called ``admin.py`` inside the
``world`` application, and insert the following::
from django.contrib.gis import admin