Code

Changes between Version 76 and Version 77 of GeoDjango


Ignore:
Timestamp:
06/04/07 05:16:45 (7 years ago)
Author:
jbronn
Comment:

updated the TOC for separate pages

Legend:

Unmodified
Added
Removed
Modified
  • GeoDjango

    v76 v77  
    1 = GeoDjango = 
     1[[TOC(GeoDjangoBackground, GeoDjango, GeoDjangoModelAPI, GeoDjangoDatabaseAPI)]] 
    22The [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. 
    3  * [GeoDjango#FAQ FAQ] 
    4  * [GeoDjango#Implementation Implementation] 
    5    * [GeoDjango#Phase1 Phase 1] 
    6    * [GeoDjango#Phase2 Phase 2] 
    7    * [GeoDjango#Phase3 Phase 3] 
    8    * [GeoDjango#DesignIssues Design Issues] 
    9    * [GeoDjango#Collaboration Collaboration] 
    10  * [GeoDjango#Example Example] 
    11    * [GeoDjango#GeographicModels Geographic Models] 
    12    * [GeoDjango#Usingsyncdb Using syncdb] 
    13    * [GeoDjango#SpatialQueries Spatial Queries] 
    14  * [GeoDjango#Installation Installation] 
    15    * [GeoDjango#Django GeoDjango Branch from SVN] ('''required''') 
    16    * [GeoDjango#GEOS GEOS] ('''required''') 
    17    * [GeoDjango#PROJ.4 PROJ.4] ('''required''') 
    18    * [GeoDjango#PostGIS PostGIS] ('''required''') 
    19    * [GeoDjango#GDAL GDAL] (''recommended'', required for some features) 
    20  * [wiki:GeoDjangoModelAPI Model API] 
    21  * [wiki:GeoDjangoDatabaseAPI Database API] 
    22  
    23 = FAQ = 
    24  * Place your questions '''here'''. 
    25  * '''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.) 
    26    * My (JDunck) reading indicates yes.  Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion. 
    27  * '''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? 
    28    * 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. 
    29  * '''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) 
    30    * 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). 
    31  * '''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." 
    32    * 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. 
    333 
    344= Implementation = 
     
    8151 * [http://exogen.case.edu/projects/geopy/ geopy] 
    8252   * Brian Beck has written a good foundation for geocoding and distance calculations, BSD licensed. 
     53 
     54= FAQ = 
     55 * Place your questions '''here'''. 
     56 * '''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.) 
     57   * My (JDunck) reading indicates yes.  Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion. 
     58 * '''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? 
     59   * 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. 
     60 * '''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) 
     61   * 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). 
     62 * '''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." 
     63   * 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. 
    8364 
    8465= Example = 
     
    130111}}} 
    131112 
    132 '''Note:'''  The geometry columns are created outside of the {{{CREATE TABLE}}} statements by the {{{AddGeometryColumn}}}.  This is done according to the OpenGIS specfication.  ''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). 
     113'''Note:'''  The geometry columns are created outside of the {{{CREATE TABLE}}} statements by the {{{AddGeometryColumn}}}.  This is done according to the OpenGIS specfication. 
     114 * ''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). 
    133115 
    134116== Spatial Queries ==