Changes between Version 52 and Version 53 of GeoDjango

Timestamp:

Mar 30, 2007, 10:31:14 PM (18 years ago)

Author:

jbronn

Comment:

updated db_api, FAQ

GeoDjango

@@ -58 +58 @@
 = FAQ =
  * Place your questions '''here'''.
- * '''Q:'''When dealing with points (say, degrees) from, do they need to be converted to be useful on the back-end data, assuming -that- data is in degrees?  Is it enough to have the same datum and origin?  (Reading the intro above is likely to answer the question.)
+ * '''Q:''' When dealing with points (say, degrees) from, do they need to be converted to be useful on the back-end data, assuming -that- data is in degrees?  Is it enough to have the same datum and origin?  (Reading the intro above is likely to answer the question.)
    * 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/es/spatial-extensions.html MySQL spatial-extensions]. If not, it's planned?
+ * '''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.
 
 
@@ -71 +72 @@
 == Phase 2 ==
  * Add as much from the PostGIS API as possible.
- * Finish PostGIS indexing capability.
+ * 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.
+
+== Phase 3 ==
+ * Support MySQL databases.
 
 == Collaboration ==
@@ -258 +262 @@
 
  * ''See generally'', [http://postgis.refractions.net/docs/ch06.html#id2618041 "Operators", PostGIS Documentation at Ch. 6.2.2]
- * '''Note:'''  This API is subject to some change, ''i.e.'', {{{overlapsbelow}}} is expected to become {{{overlaps_below}}}.
- * {{{overlapsleft}}}
+ * '''Note:'''  This API is subject to some change -- we're open to suggestions.
+ * {{{overlaps_left}}}
    * Returns true if A's bounding box overlaps or is to the left of B's bounding box.
    * PostGIS equivalent "{{{&<}}}"
- * {{{overlapsright}}} 
+ * {{{overlaps_right}}} 
    * Returns true if A's bounding box overlaps or is to the right of B's bounding box.
    * PostGIS equivalent "{{{&>}}}"
@@ -271 +275 @@
    * Returns true if A's bounding box is strictly to the right of B's bounding box.
    * PostGIS equivalent "{{{>>}}}"
- * {{{overlapsbelow}}}
+ * {{{overlaps_below}}}
    * Returns true if A's bounding box overlaps or is below B's bounding box.
    * PostGIS equivalent "{{{&<|}}}"
- * {{{overlapsabove}}}
+ * {{{overlaps_above}}}
    * Returns true if A's bounding box overlaps or is above B's bounding box.
    * PostGIS equivalent "{{{|&>}}}"
- * {{{strictlybelow}}}
+ * {{{strictly_below}}}
    * Returns true if A's bounding box is strictly below B's bounding box.
    * PostGIS equivalent "{{{<<|}}}"
- * {{{strictlyabove}}}
+ * {{{strictly_above}}}
    * Returns true if A's bounding box is strictly above B's bounding box.
    * PostGIS equivalent "{{{|>>}}}"
- * {{{sameas}}}
+ * {{{same_as}}}
    * The "same as" operator. It tests actual geometric equality of two features. So if A and B are the same feature, vertex-by-vertex, the operator returns true.
    * PostGIS equivalent "{{{~=}}}"