Changes between Version 111 and Version 112 of GeoDjango


Ignore:
Timestamp:
Apr 24, 2008, 6:57:50 PM (16 years ago)
Author:
jbronn
Comment:

Updated.

Legend:

Unmodified
Added
Removed
Modified

  • GeoDjango

    v111 v112  
    1818 * [wiki:GeoDjangoExtras Extra Features] (in progress).
    1919
    20 This 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.
     20This 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.
    2121
    2222== Roadmap ==
    … …  
    2626=== Pending Features ===
    2727The following is a discussion of features we hope to implement in !GeoDjango.  Unless stated otherwise, features in this list are not prioritized.  If you have a pet feature you may accelerate its development by submitting code yourself.
    28  * Support for a mapping framework (''e.g.'', Open Layers, Google Maps/Earth, Yahoo Maps, MS Live, etc.)
     28 * Support for a mapping framework (e.g., OpenLayers, Google Maps/Earth, Yahoo Maps, MS Live, etc.)
    2929   * Admin fields and forms (WKT field currently as of r4884, but we want widgets to view and manipulate geographic objects).
    3030   * Progress has been made on this front by multiple parties; we are currently utilizing `newforms-admin`, but are waiting for it to merge before committing any code.
    … …  
    3232 * Additional features available in PostGIS API.
    3333 * Support additional spatial databases:
    34    * Maybe DB2 and SQL Server 2008
     34   * Maybe sqlite (via [http://www.gaia-gis.it/spatialite/ SpatialLite]), DB2 and SQL Server 2008
    3535
    3636=== Milestones ===
    … …  
    4343 * r6108: Created the `maps` module, which includes rudimentary support for generating Google Maps.
    4444 * 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].
    45  * r5529: Added utilities for importing vector data (''e.g.'', SHP files) directly into !GeoDjango models. 
     45 * r5529: Added utilities for importing vector data (e.g., SHP files) directly into !GeoDjango models. 
    4646     * 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].
    47  * 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]. 
    48    * {{{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()}}}).
    49    * {{{SpatialReference}}}: Wraps [http://www.gdal.org/ogr/classOGRSpatialReference.html OGR Spatial Reference] objects, may be used to transform OGR geometries.
    50    * {{{DataSource}}}: Wraps [http://www.gdal.org/ogr/classOGRDataSource.html OGR Data Source] objects, may be used to explore GDAL-supported data sources
    51  * r5008: Added a {{{ctypes}}} interface for [http://geos.refractions.net/ GEOS] in [source:django/branches/gis/django/contrib/gis/gdal django.contrib.gis.geos].
    52    * {{{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.
     47 * 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]. 
     48   * `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()`).
     49   * `SpatialReference`: Wraps [http://www.gdal.org/ogr/classOGRSpatialReference.html OGR Spatial Reference] objects, may be used to transform OGR geometries.
     50   * `DataSource`: Wraps [http://www.gdal.org/ogr/classOGRDataSource.html OGR Data Source] objects, may be used to explore GDAL-supported data sources
     51 * r5008: Added a `ctypes` interface for [http://geos.refractions.net/ GEOS] in [source:django/branches/gis/django/contrib/gis/gdal django.contrib.gis.geos].
     52   * `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.
    5353 * r4851: Added PostGIS indexing capability.
    5454
    … …  
    5757=== Design Issues ===
    5858 * Client JS/Flash framework.  The `maps` module will be added soon, support for the following APIs will be implemented, or is being considered
    59    * [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.
    60    * {{{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.
    61    * [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.
     59   * [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 is included.
     60   * `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.
     61   * [http://developer.yahoo.com/maps/ Yahoo!] , [http://platform.mapquest.com/specs-free.html MapQuest], and [http://www.mapstraction.com/ Mapstraction] are all possibilities for API hooks.
    6262 * Mapping Framework (generating custom tiles, layers, labels, etc.)
    63    * [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.
    64    * [http://mapserver.gis.umn.edu/ Mapserver] is the leading open source map renderer. !MapServer is well documented 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.
     63   * [http://www.mapnik.org/ Mapnik] is a modern C++ engine that was designed for use with Python and generates beautiful maps.  However, documentation is lacking and installation is difficult.  First to use AGG rendering.
     64   * [http://mapserver.gis.umn.edu/ Mapserver] is the leading open source map renderer. !MapServer is well documented 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.
    6565 * WMS Server
    66    * 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)
     66   * 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)
    6767   
    6868=== Collaboration ===
    … …  
    8080=== Suggestions ===
    8181 * Decide what to do about "invalid" shape files, for example, float SHP field with ' ' value.
    82  * Geo field introspection.
    8382
    8483== FAQ ==
    … …  
    8786   * My (JDunck) reading indicates yes.  Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion.
    8887 * '''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?
    89    * ~~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.
     88   * ~~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.
    9089 * '''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)
    91    * 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).
    92  * '''Q:''' Per [http://groups.google.com/group/django-developers/browse_thread/thread/9f6c70864bfa7f2e/ this discussion] in {{{django-developers}}}, "I can do spatial queries if they are directly between two models with polygon fields but I can't seem to get at the spatial queries through foreign keys."
    93    * 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.
    94  * '''Q:''' Why are the OGRGeometry methods {{{transform}}} and {{{transform_to}}} separate?
     90   * 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).
     91 * '''Q:''' Per [http://groups.google.com/group/django-developers/browse_thread/thread/9f6c70864bfa7f2e/ this discussion] in `django-developers`, "I can do spatial queries if they are directly between two models with polygon fields but I can't seem to get at the spatial queries through foreign keys."
     92   * 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.
     93 * '''Q:''' Why are the OGRGeometry methods `transform` and `transform_to` separate?
    9594   * They are no longer separate, as `transform` now accepts `CoordTransform` and `SpatialReference` objects, as well as string WKT and integer SRID values (`transform` checks the input type and dispatches to the correct routine).  The former reason for the separation was that each mapped 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].  For better performance use `CoordTransform` objects when you will be performing the same transformation repeatedly.
    9695 * '''Q:''' Why don't `Q` objects work?
    … …  
    127126}}}
    128127
    129 '''Notes''':  The {{{GeoMixin}}} syntax is no longer needed as of r6467.  By default, a GiST index will be created for the School {{{PointField}}}s fields.  This behavior can be turned off by using {{{models.PointField(spatial_index=False)}}}.
     128'''Notes''':  The `GeoMixin` syntax is no longer needed as of r6467.  By default, a GiST index will be created for the School `PointField`s fields.  This behavior can be turned off by using `models.PointField(spatial_index=False)`.
    130129
    131130=== Using syncdb ===
    132 Both {{{manage.py}}} commands {{{sqlall}}} and {{{syncdb}}} work on geographic models:
     131Both `manage.py` commands `sqlall` and `syncdb` work on geographic models:
    133132{{{
    134133$ python manage.py sqlall geoapp
    … …  
    160159}}}
    161160
    162 '''Note:'''  The geometry columns are created outside of the {{{CREATE TABLE}}} statements by the {{{AddGeometryColumn}}}.  This is done according to the OpenGIS specfication.
     161'''Note:'''  The geometry columns are created outside of the `CREATE TABLE` statements by the `AddGeometryColumn`.  This is done according to the OpenGIS specfication.
    163162 * ''See'' Open GIS Consortium, Inc., ''[http://www.opengis.org/docs/99-049.pdf OpenGIS Simple Feature Specification For SQL]'', Document 99-049 (May 5, 1999), at  Ch. 2.3.8 (Geometry Values and Spatial Reference Systems, pg. 39).
    164163
    165164=== Spatial Queries ===
    166 After a geographic model has been created, the PostGIS additions to the API may be used.  Geographic queries are done normally by using {{{filter()}}} and {{{exclude()}}} on geometry-enabled models using geographic lookup types (''see'' the [wiki:GeoDjangoDatabaseAPI Database API] for lookup types).  In the following example, the {{{bbcontains}}} lookup type is used which is the same as the PostGIS {{{&&}}} operator.  It looks to see if the ''bounding box'' of the polygon contains the specific point.  The next example uses the PostGIS {{{Contains()}}} function, which calls GEOS library to test if the ''polygon'' actually contains the specific point, not just the bounding box.
     165After a geographic model has been created, the PostGIS additions to the API may be used.  Geographic queries are done normally by using `filter()` and `exclude()` on geometry-enabled models using geographic lookup types (''see'' the [wiki:GeoDjangoDatabaseAPI Database API] for lookup types).  In the following example, the `bbcontains` lookup type is used which is the same as the PostGIS `&&` operator.  It looks to see if the ''bounding box'' of the polygon contains the specific point.  The next example uses the PostGIS `Contains()` function, which calls GEOS library to test if the ''polygon'' actually contains the specific point, not just the bounding box.
    167166{{{
    168167#!python
    … …  
    172171}}}
    173172
    174 Both spatial queries and normal queries using {{{filter()}}} may be used in the same query.  For example, the following query set will only show school districts that have 'Houston' in their name and contain the given point within their polygon boundary:
     173Both spatial queries and normal queries using `filter()` may be used in the same query.  For example, the following query set will only show school districts that have 'Houston' in their name and contain the given point within their polygon boundary:
    175174{{{
    176175#!python
    … …  
    178177}}}
    179178
    180 Or combine both the bounding box routines (less accurate, fast) with the GEOS routines (most accurate, slower) to get a query that is both fast and accurate:
     179In PostGIS versions 1.2.2 and above, Refractions introduced a feature called "inline index magic" that automatically combines the indexed bounding box queries with their more computationally expensive counterparts.  Prior to this revision the following filter could be used to get the same performance benefits:
    181180{{{
    182181#!python
    183182>>> qs = District.objects.filter(poly__bbcontains='POINT(-95.362293 29.756539)').filter(poly__contains='POINT(-95.362293 29.756539)')
    184183}}}
     184
    185185
    186186=== Lazy-Geometries ===
Back to Top