Changes between Version 90 and Version 91 of GeoDjango
- Timestamp:
- Jul 31, 2007, 3:14:53 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GeoDjango
v90 v91 1 = GeoDjango = 2 1 3 [[TOC(GeoDjangoBackground, GeoDjango, GeoDjangoModelAPI, GeoDjangoDatabaseAPI)]] 2 4 The [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. … … 9 11 * [wiki:GeoDjangoDatabaseAPI Database API] 10 12 11 = Roadmap=13 == Roadmap == 12 14 13 15 '''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! 14 16 15 == Phase 1==17 === Phase 1 === 16 18 * Create Geometry-enabled fields and manager. Status: complete as of r4788. 17 19 * Allow for Geometry-enabled queries. Status: complete as of r4788. 18 20 19 == Phase 2==21 === Phase 2 === 20 22 * '''Pending''' 21 23 * Distance queries, calculations, and related utilities. … … 36 38 * 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]. 37 39 38 == Phase 3==40 === Phase 3 === 39 41 * Support additional spatial databases: 40 42 * MySQL … … 43 45 * Geocoding framework. 44 46 45 = Implementation=46 47 == Design Issues==47 == Implementation == 48 49 === Design Issues === 48 50 * Client JS/Flash framework, ''i.e.'', do we want to support OpenLayers, the Google Maps API, the Yahoo API? 49 51 * 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). … … 60 62 61 63 62 == Collaboration==64 === Collaboration === 63 65 * 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: 64 66 * Mapping framework … … 72 74 * Brian Beck has written a good foundation for geocoding and distance calculations, BSD licensed. 73 75 74 == Suggestions==76 === Suggestions === 75 77 * Decide what to do about "invalid" shape files, for example, float SHP field with ' ' value. 76 78 * Geo field introspection. 77 79 78 = FAQ=80 == FAQ == 79 81 * Place your questions '''here'''. 80 82 * '''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.) … … 89 91 * 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." 90 92 91 = Example=92 93 == Geographic Models==93 == Example == 94 95 === Geographic Models === 94 96 Here is an example of how the model API currently works (assume this example is in geo_app/models.py): 95 97 {{{ … … 113 115 '''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)}}}. 114 116 115 == Using syncdb==117 === Using syncdb === 116 118 Use the {{{manage.py}}} to invoke {{{syncdb}}} like you normally would: 117 119 {{{ … … 140 142 * ''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). 141 143 142 == Spatial Queries==144 === Spatial Queries === 143 145 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. 144 146 {{{ … … 161 163 }}} 162 164 163 = Installation=165 == Installation == 164 166 Installation 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 === 166 169 * '''Python''' 167 170 * ''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. … … 171 174 * We are currently using v8.1 of PostgreSQL, and know of no problems with 8.2 172 175 * 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 === 174 178 * GeoDjango exists in the {{{gis}}} branch from SVN: 175 179 {{{ … … 178 182 }}} 179 183 180 == GEOS==184 === GEOS === 181 185 * Latest [http://geos.refractions.net/ GEOS] version is 3.0.0RC4 182 186 * '''Update:''' As of r5008, you do ''not'' need to enable the Python bindings because GeoDjango has its own GEOS {{{ctypes}}} wrapper. … … 188 192 # make install 189 193 }}} 190 == PROJ.4 == 194 195 === PROJ.4 === 191 196 * Latest [http://proj.maptools.org/ PROJ.4] version is 4.5.0 192 197 * 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. … … 198 203 # make install 199 204 }}} 200 == PostGIS == 205 206 === PostGIS === 201 207 * Latest [http://postgis.refractions.net/download/ PostGIS] version is 1.2.1 202 208 * First build & install PostGIS. … … 223 229 224 230 * 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 === 226 233 * ''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). 227 234 * GDAL/OGR includes useful for coordinate transformations and reading/writing ''both'' vector (e.g. SHP) and raster (e.g. GeoTIFF) geographic data. … … 242 249 * ''See generally'' [http://trac.osgeo.org/gdal/wiki/GdalOgrInPython GDAL/OGR In Python] on the GDAL trac wiki. 243 250 244 == Windows==251 === Windows === 245 252 246 253 Though 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):