Changes between Version 100 and Version 101 of GeoDjango

Timestamp:

Oct 18, 2007, 8:52:01 PM (17 years ago)

Author:

jbronn

Comment:

Updated milestones, MySQL status, and info about maps module.

GeoDjango

@@ -29 +29 @@
  * WMS views.
  * Add as much from the PostGIS API as possible.
- * Support additional spatial databases, in the following order of priority.
+ * Support additional spatial databases:
    * DB2
      * When IBM DB2 Python DB-API adapter is available, work will commence on a spatial backend for DB2 [http://www-306.ibm.com/software/data/spatial/db2spatial/ Spatial Extender] add-on. ''See'' Antonio Cagiano, [http://antoniocangiano.com/2007/09/04/python-django-and-db2-status-update/ Python, Django and DB2 Status Update] blog posting.  
-   * MySQL
-     * MySQL is last because its spatial offerings are not compliant with either the OGC and SQL/MM specifications.  Specifically, all operations are limited to the bounding boxes of the geometries.
  * Geocoding framework.
 === Milestones ===
 Significant !GeoDjango changesets are mentioned below:
- * r4851: Added PostGIS indexing capability.
- * r5008: Added a {{{ctypes}}} interface for [http://geos.refractions.net/ GEOS] in [source:django/branches/gis/django/contrib/gis/gdal django.contrib.gis.geos].
-   * {{{GEOSGeometry}}}: Wraps [http://geos.refractions.net/ro/doxygen_docs/html/classgeos_1_1geom_1_1Geometry.html GEOS geometries]; all accessed geometry fields are returned as {{{GEOSGeometry}}} instances.
+ * r6527: MySQL backend added.
+ * r6524: Oracle Spatial backend added.
+ * r6497: The `GeoMixin` was completely deprecated.
+ * r6108: Created the `maps` module, which includes rudimentary support for generating Google Maps.
+ * r5657: "Lazy-Geometry" support was added (courtesy of Robert Coup's excellent patch in #4322) -- deprecating most of the  [wiki:GeoDjangoDatabaseAPI#ExtraInstanceMethods extra instance methods].
+ * r5529: Added utilities for importing vector data (''e.g.'', SHP files) directly into !GeoDjango models.  
+     * The [source:django/branches/gis/django/contrib/gis/utils/LayerMapping.py LayerMapping] class will import vector data from GDAL-supported data sources.  This is still 'beta', and requires installation of the [wiki:GeoDjango#GDAL GDAL library].
  * r5397: Added a {{{ctypes}}} interface for [http://www.gdal.org/ogr/ogr_arch.html GDAL/OGR] in [source:django/branches/gis/django/contrib/gis/gdal django.contrib.gis.gdal].  
    * {{{OGRGeometry}}}: Wraps [http://www.gdal.org/ogr/classOGRGeometry.html OGR geometries], may be accessed with an extra instance method (''e.g.'', {{{z.get_poly_ogr()}}}).
    * {{{SpatialReference}}}: Wraps [http://www.gdal.org/ogr/classOGRSpatialReference.html OGR Spatial Reference] objects, may be used to transform OGR geometries.
    * {{{DataSource}}}: Wraps [http://www.gdal.org/ogr/classOGRDataSource.html OGR Data Source] objects, may be used to explore GDAL-supported data sources 
- * r5529: Added utilities for importing vector data (''e.g.'', SHP files) directly into !GeoDjango models.  
-     * The [source:django/branches/gis/django/contrib/gis/utils/LayerMapping.py LayerMapping] class will import vector data from GDAL-supported data sources.  This is still 'beta', and requires installation of the [wiki:GeoDjango#GDAL GDAL library].
- * r5657: "Lazy-Geometry" support was added (courtesy of Robert Coup's excellent patch in #4322) -- deprecating most of the  [wiki:GeoDjangoDatabaseAPI#ExtraInstanceMethods extra instance methods].
- * r6497: the `GeoMixin` was completely deprecated.
- * r6524: Oracle Spatial backend added.
+ * r5008: Added a {{{ctypes}}} interface for [http://geos.refractions.net/ GEOS] in [source:django/branches/gis/django/contrib/gis/gdal django.contrib.gis.geos].
+   * {{{GEOSGeometry}}}: Wraps [http://geos.refractions.net/ro/doxygen_docs/html/classgeos_1_1geom_1_1Geometry.html GEOS geometries]; all accessed geometry fields are returned as {{{GEOSGeometry}}} instances.
+ * r4851: Added PostGIS indexing capability.
+
 == Implementation ==
 
 === Design Issues ===
- * Client JS/Flash framework.  A {{{maps}}} module will be added soon, support for the following APIs will be implemented, or is being considered
-   * {{{django.contrib.gis.maps.google}}}: This forthcoming module will contain {{{GoogleMap}}} object, which generates basic Google Maps API !JavaScript from customizable templates.  Automatic zoom-level determination of geometries will be included.
-   * {{{django.contrib.gis.maps.openlayers}}}: Work will begin on a similar !JavaScript utility for [http://www.openlayers.org/ OpenLayers], which is ''the'' open source web mapping framework.  Well-tested, BSD-licensed, and includes multitudes of features; for example, !OpenLayers supports WMS/WFS/tiles as well as Google, MS Virtual Earth, and Yahoo layers.
+ * Client JS/Flash framework.  The `maps` module will be added soon, support for the following APIs will be implemented, or is being considered
+   * [browser:django/branches/gis/django/contrib/gis/maps/google django.contrib.gis.maps.google]: Contains the `GoogleMap` object, which generates basic Google Maps API !JavaScript from customizable templates.  Automatic zoom-level determination of geometries is accomplished via the `GoogleZoom` object.
+   * {{{django.contrib.gis.maps.openlayers}}}: Similar plans are in place for a [http://www.openlayers.org/ OpenLayers] module, which is ''the'' open source web mapping framework.  Well-tested, BSD-licensed, and includes multitudes of features; for example, !OpenLayers supports WMS/WFS/tiles as well as Google, MS Virtual Earth, and Yahoo layers.  ''See also'' ticket #5472.
    * [http://developer.yahoo.com/maps/ Yahoo!] has a really slick flash interface, I'd like to support this eventually, though not planned at this time.
  * Mapping Framework (generating custom tiles, layers, labels, etc.)
@@ -83 +84 @@
    * 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, unfortunately support is not planned because MySQL's complete support of spatial queries will not be available until 7.0 (''see'' my [http://postgis.refractions.net/pipermail/postgis-users/2007-August/016612.html email to postgis-users] for more details).  As a spatial database PostGIS it is standards compliant (OpenGIS consortium), more widely used, and has more features (''e.g.'', coordinate transformation, {{{geometry_columns}}} and {{{spatial_ref_sys}}} tables).  Until this situation improves, MySQL spatial support will not be a priority, but, I'm open to committing a user-contributed spatial backend for MySQL's current limited spatial offerings.
+   * ~~No, unfortunately support is not planned.~~ Support for MySQL was added as of r6527. The changes required for the Oracle backend made it relatively easy to implement one for MySQL.  However, MySQL is limited to bounding-box queries only, and many advanced features (''e.g.'', coordinate transformation, {{{geometry_columns}}} and {{{spatial_ref_sys}}} tables) are missing because of MySQL's implementation.  Furthermore, MySQL's spatial indexes are limited to MyISAM tables, which are not transactional.
  * '''Q:''' Is this going to be a WMS Server/WMS Client/Both?  OWSLib is just a WMS Client from what I have seen (from ruckc)
    * WMS Server first, client capability a possibility in certain situations (i.e. you want to cache data from another WMS server).  Yes, OWSLib is a client, but it contains code for validating the correct parameters to send to a WMS server, thus it can be adapted into a Django view that validates whether the proper WMS parameters were given.  Mapnik has an {{{ogcserver}}} module that can parse the correct parameters for WMS 1.1.1 and 1.3.0, however since it is licensed under the LGPL it cannot be easily incorporated into this branch (unlike OWSLib).