Changes between Version 40 and Version 41 of GeoDjango


Ignore:
Timestamp:
Mar 24, 2007, 1:29:48 PM (18 years ago)
Author:
jbronn
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GeoDjango

    v40 v41  
    4040 * Create Geometry-enabled fields and manager.  Status: complete as of r4788.
    4141 * Allow for Geometry-enabled queries.  Status: complete as of r4788.
    42  * Here is an example of how the model API currently works (assume this example is in geo_app/models.py):
     42
     43== Phase 2 ==
     44 * Add as much from the PostGIS API as possible.
     45 * Finish PostGIS indexing capability.
     46 * Admin fields and forms.
     47 * Add geometry-enabled routines to the fields that call directly on GEOS routines -- like area(), centroid(), etc.
     48 * Support for mapping frameworks.
     49 * Utilities for importing raster data (SHP files first) directly into Django models.
     50
     51== Collaboration ==
     52 * PCL (Python Cartographic Library), now part of [http://www.gispython.org/ GIS Python], has done a lot of good work already. Let's apply the DRY principle.
     53 * Strong opportunities for collaboration with regards to:
     54   * Mapping framework
     55   * Utilities
     56   * Database representation ideas
     57   * WMS/WMF Framework
     58   * GEOS support, Sean Gilles (lead developer of PCL) looking for help maintaining Python/SWIG interface to GEOS.  If SWIG interface no longer maintained, might have to move to PCL for up-to-date GEOS library support.
     59
     60= Example =
     61Here is an example of how the model API currently works (assume this example is in geo_app/models.py):
    4362{{{
    4463from django.contrib.gis.db import models
     
    5877}}}
    5978
    60  * Use the manage.py just like you normally would:
     79Use the {{{manage.py}}} just like you normally would:
    6180{{{
    6281$ python manage.py sqlall geo_app
     
    7897}}}
    7998
    80   * PostGIS additions to the API may now be used.  Geographic queries are done by calling {{{geo_filter()}}} and {{{geo_exclude}}} on geometry-enabled models.  In the following example, the {{{bbcontains}}} lookup type is used which is the same as the PostGIS {{{&&}}} operator.  It looks to see if the '''bounding box''' of the polygon contains the specific point.  The next example uses the PostGIS Contains() function, which calls GEOS library to test for '''actual''' intersection of the two geometries, not just the bounding box.
     99PostGIS additions to the API may now be used.  Geographic queries are done by calling {{{geo_filter()}}} and {{{geo_exclude}}} on geometry-enabled models.  In the following example, the {{{bbcontains}}} lookup type is used which is the same as the PostGIS {{{&&}}} operator.  It looks to see if the ''bounding box'' of the polygon contains the specific point.  The next example uses the PostGIS Contains() function, which calls GEOS library to test if the ''polygon'' actually contains the specific point, not just the bounding box.
    81100{{{
    82101>>> from geo_app.models import District, School
     
    85104}}}
    86105
    87   * Both {{{geo_filter()}}} and {{{filter()}}} may be used in the same query.  For example, the following query set will only show school districts that have 'Houston' in their name and contain the given point within their polygon boundary:
     106Both {{{geo_filter()}}} and {{{filter()}}} may be used in the same query.  For example, the following query set will only show school districts that have 'Houston' in their name and contain the given point within their polygon boundary:
    88107{{{
    89108>>> qs = District.objects.filter(name__contains='Houston').geo_filter(poly__contains='POINT(-95.362293 29.756539)')
    90109}}}
    91110
    92 == Phase 2 ==
    93  * Add as much from the PostGIS API as possible.
    94  * Add geometry-enabled routines to the fields that call directly on GEOS routines -- like area(), centroid(), etc.
    95  * Contemplate a JS framework for mapping.  I know Django community is against including any type of JS/AJAX framework, but having a way to generate maps would be a great addition.  Also, any type of framework would be limited to the contrib package only.
     111Or combine both the bounding box routines (less accurate, fast) with the GEOS routines (most accurate, slower) to get a query that is both fast and accurate (this is not 'fast' in the current implementation, since geographic indices are not automatically created):
     112{{{
     113>>> qs = District.objects.geo_filter(poly__bbcontains='POINT(-95.362293 29.756539)').geo_filter(poly__contains='POINT(-95.362293 29.756539)')
     114}}}
    96115
    97116= Installation =
Back to Top