Code

Changes between Version 55 and Version 56 of GeoDjango


Ignore:
Timestamp:
03/31/07 14:51:26 (7 years ago)
Author:
jbronn
Comment:

cleaned up phase 2 a bit, cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • GeoDjango

    v55 v56  
    5555 
    5656== Useful Data == 
    57  * [http://www.census.gov/geo/www/tiger/tiger2006fe/tgr2006fe.html TIGER/Line]: "The TIGER/Line files are extracts of selected geographic and cartographic information from the [http://www.census.gov/ Census Bureau's] TIGER®  (Topologically Integrated Geographic Encoding and Referencing) database."  This data is useful in creating your own geocoding database service.  Currently 2006 First Edition is the latest, but second edition should be coming soon.  Note: The Census Bureau will be [http://www.census.gov/geo/www/tiger/tgrshp.html providing SHP files] in Fall, 2007.   
     57 * [http://www.census.gov/geo/www/tiger/tiger2006se/tgr2006se.html TIGER/Line]: "The TIGER/Line files are extracts of selected geographic and cartographic information from the [http://www.census.gov/ Census Bureau's] TIGER®  (Topologically Integrated Geographic Encoding and Referencing) database."  This data is useful in creating your own geocoding database service.  Currently 2006 Second Edition is the latest.  Note: The Census Bureau will be [http://www.census.gov/geo/www/tiger/tgrshp.html providing SHP files] in Fall, 2007.   
    5858 
    5959= FAQ = 
     
    6262   * My (JDunck) reading indicates yes.  Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion. 
    6363 * '''Q:''' Can this implementation work with [http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html MySQL spatial-extensions]. If not, it's planned? 
    64    * No.  Yes it's (now) planned, ''see'' Phase 3 below.  From the last time I (jbronn) checked, MySQL's spatial capabilities have improved.  However, we're going to focus our efforts on PostGIS until things are worked out a bit more -- as a spatial database it is more standards compliant (OpenGIS consortium), more widely used, and has more features (e.g. coordinate transformation, {{{geometry_columns}}} and {{{spatial_ref_sys}}} tables).  It is definitely something I would want to implement in the future since I do ''like'' MySQL. 
     64   * No.  It is (now) planned, ''see'' Phase 3 below.  From the last time I (jbronn) checked, MySQL's spatial capabilities have improved.  However, we're going to focus our efforts on PostGIS until things are worked out a bit more.  As a spatial database PostGIS it is more standards compliant (OpenGIS consortium), more widely used, and has more features (e.g. coordinate transformation, {{{geometry_columns}}} and {{{spatial_ref_sys}}} tables).  It is definitely something I would want to implement in the future since I do ''like'' MySQL. 
    6565 
    6666 
     
    7272 
    7373== Phase 2 == 
    74  * Add as much from the PostGIS API as possible. 
    75  * Finish PostGIS indexing capability (complete). 
    76  * Admin fields and forms. 
    77  * Add geometry-enabled routines to the fields that call directly on GEOS routines -- like area(), centroid(), etc. 
    78  * Support for mapping frameworks. 
    79  * Utilities for importing raster data (SHP files first) directly into Django models. 
     74 * '''Pending''' 
     75   * 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)  
     76   * Admin fields and forms (WKT field currently as of r4884, but we want widgets to view and manipulate geographic objects). 
     77   * Add as much from the PostGIS API as possible. 
     78   * Support for mapping frameworks (e.g. Google Maps/Earth, Yahoo Maps, MS Live, etc.) 
     79   * Utilities for importing raster data (SHP files first) directly into Django models. 
     80 * '''Complete''' 
     81   * PostGIS indexing capability 
    8082 
    8183== Phase 3 == 
     
    341343== get_GEOM_wkt == 
    342344 
    343 For every geometry field, the model object will have a {{{get_FOO_wkt}}} method, where {{{FOO}}} is the name of the geometry field.  For example (using the {{{School}}} model from above): 
     345For 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): 
    344346 
    345347{{{ 
     
    351353== get_GEOM_centroid == 
    352354 
    353 For every geometry field, the model object will have a {{{get_FOO_centroid}}} method, where {{{FOO}}} is the name of the geometry field.  This routine will return the centroid of the geometry.  For example (using the {{{District}}} model from above): 
     355For 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): 
    354356 
    355357{{{ 
     
    361363== get_GEOM_area == 
    362364 
    363 For every geometry field, the model object will have a {{{get_FOO_area}}} method, where {{{FOO}} is the name of the geometry field.  This routine will return the area of the geometry. 
     365For 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. 
    364366 
    365367{{{