Code

Changes between Version 90 and Version 91 of GeoDjango


Ignore:
Timestamp:
07/31/07 13:14:53 (7 years ago)
Author:
adrian
Comment:

Added a main headline for the page, and changed the other titles to be one level down

Legend:

Unmodified
Added
Removed
Modified
  • GeoDjango

    v90 v91  
     1= GeoDjango = 
     2 
    13[[TOC(GeoDjangoBackground, GeoDjango, GeoDjangoModelAPI, GeoDjangoDatabaseAPI)]] 
    24The [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. 
     
    911 * [wiki:GeoDjangoDatabaseAPI Database API] 
    1012 
    11 = Roadmap = 
     13== Roadmap == 
    1214 
    1315'''Note:''' In order to minimize confusion, please don't modify the official roadmap below.  If you have a suggestion, place it in the [wiki:GeoDjango#Suggestions suggestion section] or ask your question in the [wiki:GeoDjango#FAQ FAQ].  If your request is urgent, submit a ticket requesting your feature or bugfix (make sure to specify the component as 'GIS').  Thanks for your cooperation! 
    1416 
    15 == Phase 1 == 
     17=== Phase 1 === 
    1618 * Create Geometry-enabled fields and manager.  Status: complete as of r4788. 
    1719 * Allow for Geometry-enabled queries.  Status: complete as of r4788. 
    1820 
    19 == Phase 2 == 
     21=== Phase 2 === 
    2022 * '''Pending''' 
    2123   * Distance queries, calculations, and related utilities. 
     
    3638   * As of 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]. 
    3739 
    38 == Phase 3 == 
     40=== Phase 3 === 
    3941 * Support additional spatial databases: 
    4042   * MySQL 
     
    4345 * Geocoding framework. 
    4446 
    45 = Implementation = 
    46  
    47 == Design Issues == 
     47== Implementation == 
     48 
     49=== Design Issues === 
    4850 * Client JS/Flash framework, ''i.e.'', do we want to support OpenLayers, the Google Maps API, the Yahoo API?   
    4951   * 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). 
     
    6062    
    6163 
    62 == Collaboration == 
     64=== Collaboration === 
    6365 * 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: 
    6466   * Mapping framework 
     
    7274   * Brian Beck has written a good foundation for geocoding and distance calculations, BSD licensed. 
    7375 
    74 == Suggestions == 
     76=== Suggestions === 
    7577 * Decide what to do about "invalid" shape files, for example, float SHP field with ' ' value. 
    7678 * Geo field introspection. 
    7779 
    78 = FAQ = 
     80== FAQ == 
    7981 * Place your questions '''here'''. 
    8082 * '''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.) 
     
    8991   * 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." 
    9092 
    91 = Example = 
    92  
    93 == Geographic Models == 
     93== Example == 
     94 
     95=== Geographic Models === 
    9496Here is an example of how the model API currently works (assume this example is in geo_app/models.py): 
    9597{{{ 
     
    113115'''Notes''':  The {{{GeoMixin}}} class allows for [wiki:GeoDjangoDatabaseAPI#ExtraInstanceMethods extra instance methods].  By default, a GiST index will be created for the School {{{PointField}}}s fields.  This behavior can be turned off by using {{{models.PointField(index=False)}}}.  
    114116 
    115 == Using syncdb == 
     117=== Using syncdb === 
    116118Use the {{{manage.py}}} to invoke {{{syncdb}}} like you normally would: 
    117119{{{ 
     
    140142 * ''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). 
    141143 
    142 == Spatial Queries == 
     144=== Spatial Queries === 
    143145After 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. 
    144146{{{ 
     
    161163}}} 
    162164 
    163 = Installation = 
     165== Installation == 
    164166Installation of the GeoDjango module will also require the installation of existing open source geographic libraries and a spatial database (currently only PostGIS).  This section will describe the installation process for these libraries.  Initially, these instructions will pertain only to a Linux platform (particularly Debian or Ubuntu).  Mac & Windows support will be considered later; however, these instructions will most likely work through the Mac shell. 
    165 == Python & PostgreSQL == 
     167 
     168=== Python & PostgreSQL === 
    166169 * '''Python''' 
    167170   * ''Required:'' Python 2.4 is required because of heavy use of 2.4 decorator syntax (''e.g.'' {{{@property}}}).  The {{{ctypes}}} module needs to be installed as well. 
     
    171174   * We are currently using v8.1 of PostgreSQL, and know of no problems with 8.2 
    172175   * On Ubuntu Feisty, you'll need the apt packages {{{postgresql-server-dev-8.x}}} (the development headers are needed for PostGIS compilation) and {{{postgresql-8.x}}}. 
    173 == Django == 
     176 
     177=== Django === 
    174178 * GeoDjango exists in the {{{gis}}} branch from SVN: 
    175179{{{ 
     
    178182}}} 
    179183 
    180 == GEOS == 
     184=== GEOS === 
    181185 * Latest [http://geos.refractions.net/ GEOS] version is 3.0.0RC4 
    182186 * '''Update:''' As of r5008, you do ''not'' need to enable the Python bindings because GeoDjango has its own GEOS {{{ctypes}}} wrapper. 
     
    188192# make install 
    189193}}} 
    190 == PROJ.4 == 
     194 
     195=== PROJ.4 === 
    191196 * Latest [http://proj.maptools.org/ PROJ.4] version is 4.5.0 
    192197 * First, download the PROJ [ftp://ftp.remotesensing.org/proj/proj-datumgrid-1.3.tar.gz datum shifting files].  These will come in handy for coordinate transformations when other programs (like Mapserver or Mapnik) are not able to cope with EPSG transformations (I learned the hard way). Untar/unzip these in the {{{nad}}} subdirectory of the PROJ source.  For example, if PROJ was unzipped in a directory named {{{proj}}}, then untar these files in {{{proj/nad}}}.  Do this '''before''' you do the configure/make/install dance. 
     
    198203# make install  
    199204}}} 
    200 == PostGIS == 
     205 
     206=== PostGIS === 
    201207 * Latest [http://postgis.refractions.net/download/ PostGIS] version is 1.2.1 
    202208 * First build & install PostGIS. 
     
    223229  
    224230 * Finally, update your {{{settings.py}}} to reflect the name and user for the spatially enabled database.  So far, we only plan to support the psycopg2 backend, thus: {{{DATABASE_ENGINE='postgresql_psycopg2'}}}. 
    225 == GDAL == 
     231 
     232=== GDAL === 
    226233 * ''Highly Recommended'': Some features (e.g. a large number of {{{SpatialRefSys}}} model routines) require GDAL, but it is not necessary for core functionality (e.g. spatial queries). 
    227234 * GDAL/OGR includes useful for coordinate transformations and reading/writing ''both'' vector (e.g. SHP) and raster (e.g. GeoTIFF) geographic data. 
     
    242249   * ''See generally'' [http://trac.osgeo.org/gdal/wiki/GdalOgrInPython GDAL/OGR In Python] on the GDAL trac wiki. 
    243250 
    244 == Windows == 
     251=== Windows === 
    245252 
    246253Though GeoDjango is not yet "officially" supported for Windows (due to documentation, see #4397), our ctypes interfaces have made compatibility with Windows 2000/XP a reality.  The developer uses binary libraries from the following open-source projects (for Windows):