Changes between Version 66 and Version 67 of GeoDjango

Timestamp:

Apr 15, 2007, 11:22:30 PM (18 years ago)

Author:

jbronn

Comment:

updated for new GEOS library; updated GDAL install

GeoDjango

@@ -82 +82 @@
 == Phase 2 ==
  * '''Pending'''
-   * Add geometry-enabled routines to the fields that call directly on GEOS routines -- like area(), centroid(), etc. (partially complete as of r4884. ''See'' [GeoDjango#ExtraInstanceMethods Extra Instance Methods] section below) 
    * Add as much from the PostGIS API as possible.
    * Support for a mapping framework (e.g. Google Maps/Earth, Yahoo Maps, MS Live, etc.)
@@ -88 +87 @@
    * Utilities for importing raster data (SHP files first) directly into Django models.
  * '''Complete'''
-   * PostGIS indexing capability
+   * PostGIS indexing capability.
+   * As of r5008, added a GEOS wrapper object for geometry-enabled fields that call directly on GEOS routines (''e.g.'' {{{z.get_poly_geos().area}}}).  ''See'' [GeoDjango#ExtraInstanceMethods Extra Instance Methods] section below) 
 
 == Phase 3 ==
@@ -102 +102 @@
    * [http://mapserver.gis.umn.edu/ Mapserver] has been around for a while, strong backing in the community (e.g. native support in [http://qgis.org/ QGIS]).  Even with documentation, the code looks less inviting than Mapnik (all in C); also has archaic text-based configuration files (pre-dating markup languages).
  * GEOS
+   * '''Update:''' As of r5008, GeoDjango has its own GEOS interface (via {{{ctypes}}})
    * GEOS is no longer maintained by Sean Gillies.  ''See'' Sean Gillies, ''[http://zcologia.com/news/150/geometries-for-python/ Geometries for Python]'' (blog post explaining rationale for abandoning GEOS support); ''see also'' Sean's message on the [http://geos.refractions.net/pipermail/geos-devel/2007-March/002851.html GEOS-Devel Mailing List] (Mar. 5, 2007).
    * Might consider either using PCL or implement a {{{ctypes}}} wrapper for the routines that we need -- can't really port PCL code here because it is GPL (Django is licensed under BSD).
@@ -201 +202 @@
 == GEOS ==
  * Latest [http://geos.refractions.net/ GEOS] version is 3.0.0RC4
-   * Also requires SWIG >= 1.3.28.  (Ubuntu Dapper comes with 1.3.27.)
-   * If there's trouble locating your python, include {{{PYTHON=/path/to/python}}}, or {{{--enable-python=/path/to/python}}}.
- * Configure (enabling python), make, and install.
-{{{
-$ ./configure --enable-python
+ * '''Update:''' As of r5008, you do ''not'' need to enable the Python bindings because GeoDjango has its own GEOS {{{ctypes}}} wrapper.
+   * {{{ctypes}}} comes standard with Python 2.5.  If you run Python 2.4, {{{ctypes}}} may be [http://sourceforge.net/project/showfiles.php?group_id=71702&package_id=71318 downloaded here]
+ * Configure, make, and install.
+{{{
+$ ./configure
 $ make
 # make install
@@ -250 +251 @@
 ogr2ogr -t_srs WGS84 output.shp input.shp
 }}}
- * Latest [http://www.gdal.org/download.html GDAL] version is 1.4.0.  Configure with GEOS and Python support, then make and install:
-{{{
-$ ./configure --with-geos --with-python
+ * Latest [http://www.gdal.org/download.html GDAL] version is 1.4.1.  Configure with GEOS and Python support, then make and install:
+{{{
+$ ./configure --with-geos --with-ngpython
 $ make
 # make install
 }}}
- * ''Note'': This is done without the 'next generation' SWIG Python bindings. I've had trouble getting them to work, and the rumor is this only works on Windows. The compilation flag to enable these is {{{--with-ngpython}}}, but our packages currently only use the old bindings.
+ * ''Note'': This is done with the 'next generation' SWIG Python bindings. The compilation flag to enable the old bindings (no longer supported) is {{{--with-python}}}.
 
 = Model API =
@@ -390 +391 @@
 A model with geometry fields will get the following methods:
 
+== get_GEOM_geos ==
+For every geometry field the model instance will have a {{{get_GEOM_geos}}} method, where {{{GEOM}}} is the name of the geometry field.  Returns a {{{GEOSGeometry}}} instance for the geometry.  For example (using the {{{District}}} model from above):
+
+{{{
+#!python
+>>> from django.contrib.gis.geos import GEOSGeometry
+>>> dist = District.objects.get(name='Houston ISD')
+>>> geom = dist.get_poly_geos()
+>>> print geom.centroid.wkt
+POINT(-95.231713 29.723235)
+>>> print geom.area
+0.08332
+>>> print geom.geom_type
+Polygon
+>>> print geom.centroid.geom_type
+Point
+>>> print geom.intersects(GEOSGeometry('POINT(-95.395223 29.798088)'))
+False
+}}}
+
 == get_GEOM_wkt ==
 
-For every geometry field, the model object will have a {{{get_GEOM_wkt}}} method, where {{{GEOM}}} is the name of the geometry field.  For example (using the {{{School}}} model from above):
+For every geometry field, the model instance will have a {{{get_GEOM_wkt}}} method, where {{{GEOM}}} is the name of the geometry field.  For example (using the {{{School}}} model from above):
 
 {{{
@@ -403 +424 @@
 == get_GEOM_centroid ==
 
-For every geometry field, the model object will have a {{{get_GEOM_centroid}}} method, where {{{GEOM}}} is the name of the geometry field.  This routine will return the centroid of the geometry.  For example (using the {{{District}}} model from above):
+For every geometry field, the model instance will have a {{{get_GEOM_centroid}}} method, where {{{GEOM}}} is the name of the geometry field.  This routine will return the centroid of the geometry.  For example (using the {{{District}}} model from above):
 
 {{{
@@ -414 +435 @@
 == get_GEOM_area ==
 
-For every geometry field, the model object will have a {{{get_GEOM_area}}} method, where {{{GEOM}}} is the name of the geometry field.  This routine will return the area of the geometry.
+For every geometry field, the model instance will have a {{{get_GEOM_area}}} method, where {{{GEOM}}} is the name of the geometry field.  This routine will return the area of the geometry.
 
 {{{