Changes between Version 95 and Version 96 of GeoDjango


Ignore:
Timestamp:
Sep 7, 2007, 9:31:10 PM (17 years ago)
Author:
jbronn
Comment:

added links to extras features, updated roadmap and implementation sections

Legend:

Unmodified
Added
Removed
Modified

  • GeoDjango

    v95 v96  
    11= !GeoDjango =
    22
    3 [[TOC(GeoDjangoBackground, GeoDjango, GeoDjangoInstall, GeoDjangoModelAPI, GeoDjangoDatabaseAPI, GEOSGeometry)]]
     3[[TOC(GeoDjangoBackground, GeoDjango, GeoDjangoInstall, GeoDjangoModelAPI, GeoDjangoDatabaseAPI, GEOSGeometry, GeoDjangoExtras)]]
    44The [http://code.djangoproject.com/browser/django/branches/gis GIS] branch intends to be a world-class geographic web framework.  Our goal is to make it as easy as possible to build GIS web applications and harness the power of spatially enabled data.
    55
    … …  
    1212 * [wiki:GeoDjangoDatabaseAPI Database API]
    1313 * [wiki:GEOSGeometry GEOS Geometries] (in progress).
     14 * [wiki:GeoDjangoExtras Extra Features] (in progress).
     15
     16This documentation is behind the current feature-set -- when in doubt use {{{help}}} on the feature in question, as most [browser:django/branches/gis/django/contrib/gis GeoDjango modules] and routines have docstrings.
    1417
    1518== Roadmap ==
    … …  
    2326=== Phase 2 ===
    2427 * '''Pending'''
    25    * Distance queries, calculations, and related utilities.
    26    * Support for a mapping framework (e.g. Google Maps/Earth, Yahoo Maps, MS Live, etc.)
     28   * Distance queries, calculations, and related utilities.  Status:
     29     * Robert Coup has contributed the excellent [http://code.djangoproject.com/browser/django/branches/gis/django/contrib/gis/measure.py measure] module (in {{{django.contrib.gis.measure}}}), allowing for easy comparison of distances in a variety of formats (currently supported: feet, meters, yards, kilometers, miles, and nautical miles)
     30     * No support in the database API yet, but performing spatial queries using output from the [wiki:GEOSGeometry GEOS] {{{buffer()}}} function may tide you over until we implement full support.
     31   * Support for a mapping framework (''e.g.'', Google Maps/Earth, Yahoo Maps, MS Live, etc.)
    2732     * Admin fields and forms (WKT field currently as of r4884, but we want widgets to view and manipulate geographic objects).
    2833   * WMS views.
    … …  
    4146
    4247=== Phase 3 ===
    43  * Support additional spatial databases:
     48 * Support additional spatial databases, in the following order of priority.
     49   * DB2
     50     * 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. 
     51   * Oracle Spatial (but only if I (jbronn) have access to a valid license)
    4452   * MySQL
    45    * DB2
    46    * Oracle Spatial (I (jbronn) would need access to a license to make this happen)
     53     * 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.
    4754 * Geocoding framework.
    4855
    … …  
    5057
    5158=== Design Issues ===
    52  * Client JS/Flash framework, ''i.e.'', do we want to support OpenLayers, the Google Maps API, the Yahoo API? 
    53    * So far, Google Maps looks the most promising for being supported first (people are familiar with it, and it's more stable than open layers).
    54    * [http://developer.yahoo.com/maps/ Yahoo!] has a really slick flash interface, I'd like to support this eventually.
    55    * [http://www.openlayers.org/ OpenLayers] supports WMS/WFS/tiles as well as Google, MSVE, and Yahoo layers. It is very flexible and open(!!). ''(Rob Coup)''
     59 * Client JS/Flash framework.  A {{{maps}}} module will be added soon, support for the following APIs will be implemented, or is being considered
     60   * {{{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.
     61   * {{{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.
     62   * [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.
    5663 * Mapping Framework (generating custom tiles, layers, labels, etc.)
    57    * [http://www.mapnik.org/ Mapnik] is modern, but very early on in development and ''completely'' lacks documentation.  However, the code is elegant and clean, and it was designed for integration with Python -- we're leaning towards this right now.
    58    * [http://mapserver.gis.umn.edu/ Mapserver] has been around for a while, strong backing in the community (e.g. native support in [http://qgis.org/ QGIS]).  Even with documentation, the code looks less inviting than Mapnik (all in C); also has archaic text-based configuration files (pre-dating markup languages).
     64   * [http://www.mapnik.org/ Mapnik] is modern, but very early on in development and ''completely'' lacks documentation.  However, the code is elegant and clean, and it was designed for integration with Python.  First to use AGG rendering.
     65   * [http://mapserver.gis.umn.edu/ Mapserver] is the leading open source map renderer. !MapServer is documented and has a strong and has strong community support.  Uses text-based configuration files, which may be difficult to set up.  AGG rendering and dynamic loading of configuration files (''e.g.'', from a string) has been added to version 5.0.
    5966 * WMS Server
    60    * I'm not satisfied with any of the current WMS/WFS implementations.   One implemented in Django would be desirable, e.g., {{{django.contrib.gis.wms}}}.  Thoughts anyone?  (OWSLib looks good, see below)
     67   * I'm not satisfied with any of the current WMS/WFS implementations.   One implemented in Django would be desirable, ''e.g.'', {{{django.contrib.gis.wms}}}.  Thoughts anyone?  (OWSLib looks good, see below)
    6168   
    62 
    6369=== Collaboration ===
    6470 * 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. Strong opportunities for collaboration with regards to:
    6571   * Mapping framework
    66    * WMS/WMF Framework -- '''[http://trac.gispython.org/projects/PCL/browser/OWSLib/trunk OWSLib]''' looks excellent for this (BSD licensed and has unit tests!)
     72   * WMS/WMF Framework -- [http://trac.gispython.org/projects/PCL/browser/OWSLib/trunk OWSLib] looks excellent for this (BSD licensed and has unit tests!)
    6773   * Utilities
    6874   * Database representation ideas
    … …  
    8288   * My (JDunck) reading indicates yes.  Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion.
    8389 * '''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?
    84    * 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.
     90   * 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.
    8591 * '''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)
    8692   * 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).
    … …  
    8894   * Geographic queries require {{{GeoManager}}}, even if the model does not have a geographic field itself (in the case of a foreign key to a geo-field).  The reply in the discussion gives detail into why.
    8995 * '''Q:''' Why are the OGRGeometry methods {{{transform}}} and {{{transform_to}}} separate?
    90    * Because these map to the separate OGR routines [http://www.gdal.org/ogr/ogr__api_8h.html#59a5b3f954b11cfbf6e78807c28d6090 OGR_G_Transform] and [http://www.gdal.org/ogr/ogr__api_8h.html#43af4c2127cea0a5059692a62c0feb63 OGR_G_TransformTo].  Specifically, the {{{transform}}} routine takes a CoordTransform object as a parameter, whereas the {{{transform_to}}} routine takes a SpatialReference object.  The {{{transform_to}}} "function requires internal creation and initialization of [a CoordTransform] object [and] it is significantly more expensive to use this function to transform many geometries than it is to create the [CoordTransform object] in advance, and call transform() with that transformation. This function exists primarily for convenience when only transforming a single geometry."
     96   * Because these map to the separate OGR routines [http://www.gdal.org/ogr/ogr__api_8h.html#59a5b3f954b11cfbf6e78807c28d6090 OGR_G_Transform] and [http://www.gdal.org/ogr/ogr__api_8h.html#43af4c2127cea0a5059692a62c0feb63 OGR_G_TransformTo].  Specifically, the {{{transform}}} routine takes a !CoordTransform object as a parameter, whereas the {{{transform_to}}} routine takes a !SpatialReference object.  The {{{transform_to}}} "function requires internal creation and initialization of [a CoordTransform] object [and] it is significantly more expensive to use this function to transform many geometries than it is to create the [CoordTransform object] in advance, and call transform() with that transformation. This function exists primarily for convenience when only transforming a single geometry."
    9197
    9298== Example ==
Back to Top