Changes between Version 55 and Version 56 of GeoDjango

Timestamp:

Mar 31, 2007, 4:51:26 PM (17 years ago)

Author:

jbronn

Comment:

cleaned up phase 2 a bit, cosmetic changes

GeoDjango

@@ -55 +55 @@
 
 == Useful Data ==
- * [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.  
+ * [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.  
 
 = FAQ =
@@ -62 +62 @@
    * My (JDunck) reading indicates yes.  Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion.
  * '''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?
-   * 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.
+   * 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.
 
 
@@ -72 +72 @@
 
 == Phase 2 ==
- * Add as much from the PostGIS API as possible.
- * Finish PostGIS indexing capability (complete).
- * Admin fields and forms.
- * Add geometry-enabled routines to the fields that call directly on GEOS routines -- like area(), centroid(), etc.
- * Support for mapping frameworks.
- * Utilities for importing raster data (SHP files first) directly into Django models.
+ * '''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) 
+   * Admin fields and forms (WKT field currently as of r4884, but we want widgets to view and manipulate geographic objects).
+   * Add as much from the PostGIS API as possible.
+   * Support for mapping frameworks (e.g. Google Maps/Earth, Yahoo Maps, MS Live, etc.)
+   * Utilities for importing raster data (SHP files first) directly into Django models.
+ * '''Complete'''
+   * PostGIS indexing capability
 
 == Phase 3 ==
@@ -341 +343 @@
 == get_GEOM_wkt ==
 
-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):
+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):
 
 {{{
@@ -351 +353 @@
 == get_GEOM_centroid ==
 
-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):
+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):
 
 {{{
@@ -361 +363 @@
 == get_GEOM_area ==
 
-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.
+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.
 
 {{{