Changes between Version 54 and Version 55 of GeoDjango
- Timestamp:
- Mar 31, 2007, 4:36:52 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GeoDjango
v54 v55 133 133 }}} 134 134 135 PostGIS additions to the API may now be used. Geographic queries are done by calling {{{geo_filter()}}} and {{{geo_exclude}}} on geometry-enabled models. 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.135 PostGIS additions to the API may now be used. Geographic queries are done by normally by using {{{filter()}}} and {{{exclude}}} on geometry-enabled models. 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. 136 136 {{{ 137 137 >>> from geo_app.models import District, School 138 >>> qs1 = District.objects. geo_filter(poly__bbcontains='POINT(-95.362293 29.756539)')139 >>> qs2 = District.objects. geo_filter(poly__contains='POINT(-95.362293 29.756539)')140 }}} 141 142 Both {{{geo_filter()}}} and{{{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:143 {{{ 144 >>> qs = District.objects.filter(name__contains='Houston'). geo_filter(poly__contains='POINT(-95.362293 29.756539)')145 }}} 146 147 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 (this is not 'fast' in the current implementation, since geographic indices are not automatically created):148 {{{ 149 >>> qs = District.objects. geo_filter(poly__bbcontains='POINT(-95.362293 29.756539)').geo_filter(poly__contains='POINT(-95.362293 29.756539)')138 >>> qs1 = District.objects.filter(poly__bbcontains='POINT(-95.362293 29.756539)') 139 >>> qs2 = District.objects.filter(poly__contains='POINT(-95.362293 29.756539)') 140 }}} 141 142 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: 143 {{{ 144 >>> qs = District.objects.filter(name__contains='Houston').filter(poly__contains='POINT(-95.362293 29.756539)') 145 }}} 146 147 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: 148 {{{ 149 >>> qs = District.objects.filter(poly__bbcontains='POINT(-95.362293 29.756539)').filter(poly__contains='POINT(-95.362293 29.756539)') 150 150 }}} 151 151 … … 236 236 237 237 * {{{srid}}} 238 * Sets the SRID of geometry to thevalue. Defaults to 4326 (WGS84)238 * Sets the SRID (Source Reference Identifier) of geometry to the given value. Defaults to 4326 (WGS84) 239 239 * {{{index}}} 240 240 * If set to True, will create a GiST index for the given geometry. Update the index with the PostgreSQL command {{{VACUUM ANALYZE}}} (may take a while to execute depending on how large your geographic-enabled tables are). … … 257 257 = Database API = 258 258 259 '''Note:''' The following database lookup types can only be used with {{{geo_filter()}}}. All geographic queries are done with {{{geo_filter()}}} and {{{geo_exclude()}}}, thus separating the normal database API lookups from geographic-specific field queries. However chains containing both {{{filter}}} and {{{geo_filter}}} may still be used. Thus, geographic queries take the following form (assuming the {{{Zip}}} model used in the [GeoDjango#ModelAPI Model API] section):260 261 {{{ 262 >>> qs = Zip.objects. geo_filter(<Zip geo field A>__<geo lookup type>=<geo string B>)263 >>> qs = Zip.objects. geo_exclude(...)259 '''Note:''' The following database lookup types can only be used with on geographic fields with {{{filter()}}}. Filters on 'normal' fields (e.g. {{{CharField}}}) may be chained with those on geographic fields. Thus, geographic queries take the following form (assuming the {{{Zip}}} model used in the [GeoDjango#ModelAPI Model API] section above): 260 261 {{{ 262 >>> qs = Zip.objects.filter(<Zip geo field A>__<geo lookup type>=<geo string B>) 263 >>> qs = Zip.objects.exclude(...) 264 264 }}} 265 265 … … 339 339 A model with geometry fields will get the following methods: 340 340 341 == get_ FOO_wkt ==341 == get_GEOM_wkt == 342 342 343 343 For every geometry field, the model object will have a {{{get_FOO_wkt}}} method, where {{{FOO}}} is the name of the geometry field. For example (using the {{{School}}} model from above): … … 349 349 }}} 350 350 351 == get_ FOO_centroid ==351 == get_GEOM_centroid == 352 352 353 353 For every geometry field, the model object will have a {{{get_FOO_centroid}}} method, where {{{FOO}}} is the name of the geometry field. This routine will return the centroid of the geometry. For example (using the {{{District}}} model from above): … … 359 359 }}} 360 360 361 == get_ FOO_area ==361 == get_GEOM_area == 362 362 363 363 For every geometry field, the model object will have a {{{get_FOO_area}}} method, where {{{FOO}} is the name of the geometry field. This routine will return the area of the geometry. … … 369 369 }}} 370 370 371 '''Note''': Units need to be figured out here.371 '''Note''': The units system needs to be figured out here, since I don't know what these units represent.