Opened 13 years ago

Closed 9 years ago

#15101 closed Bug (fixed)

GeoQuerySet extent() method fails to limit

Reported by: billtown@… Owned by: nobody
Component: GIS Version: 1.2
Severity: Normal Keywords: extent()
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by jbronn)

I have an object with geometry points.

I expected to be able to return 100 objects' extent using a limit. However as demonstrated below the limit is never in the raw sql query:

>>> test = SamAddress.objects.all()[:100].extent()
>>> print test;
(-84.390510000000006, 33.754629999999999, -77.678370000000001, 40.513269999999999)

>>> test = SamAddress.objects.all().extent()
>>> print test;
(-84.390510000000006, 33.754629999999999, -77.678370000000001, 40.513269999999999)

Debug from postgres.....

2011-01-16 18:45:04 EST LOG:  statement: SELECT ST_Extent("world_samaddress"."geometry") AS "geoagg" FROM "world_samaddress"

2011-01-16 18:45:13 EST LOG:  statement: SELECT ST_Extent("world_samaddress"."geometry") AS "geoagg" FROM "world_samaddress"

This actually makes sense since ST_Extent is indeed an aggregate function and cannot be limited (similar to count() or sum()).

I am running geodjango 1.2.3.

Version 1.3 alpha 1 SVN-14993 is different in that it does pass through the limits looking like this...

Debug from postgres

2011-01-16 17:39:10 EST LOG:  statement: SELECT ST_Extent("world_samaddress"."geometry") AS "geoagg" FROM "world_samaddress limit 100"

I don't know why my version does not use the limits on extent() and or count().
However the return value would still be the aggregate and not the limited results.

select ST_Extent(geometry) from world_samaddress limit 1;

BOX(-84.39051 33.75463,-77.67837 40.51327)

select ST_Extent(geometry) from world_samaddress;

BOX(-84.39051 33.75463,-77.67837 40.51327)

The same would go for count() (or any aggregate function?

In future versions if a subselect were used it would do what I wanted it to do (which is odd) but return the extent of 100 points.

 select ST_Extent(geometry) from (select geometry from world_samaddress limit 1) as foo;

 BOX(-84.39051 33.75463,-84.39051 33.75463)

 select ST_Extent(geometry) from (select geometry from world_samaddress) as foo;
 BOX(-84.39051 33.75463,-77.67837 40.51327)

Change History (10)

comment:1 by jbronn, 13 years ago

Description: modified (diff)

Cleaned up ticket formatting.

comment:2 by Russell Keith-Magee, 13 years ago

Triage Stage: UnreviewedAccepted

Accepting on the basis that jbronn has seen it, and didn't reject it out of hand.

comment:3 by James Addison, 13 years ago

Severity: Normal
Type: Bug

comment:4 by Aymeric Augustin, 12 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:5 by Aymeric Augustin, 12 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:6 by Reinout van Rees, 9 years ago

As you say, it isn' just an extent() problem, but also sum() and count().

Turns out, there is a ticket for the generic case of aggregates not working with limits: #12886

It is fixed in, you'll see some "force_subquery" lines in there, which matches your comment of "In future versions if a subselect were used..."

Extra note: the fix is in 1.7 and higher.

comment:7 by Sander Smits, 9 years ago

I made a pull request that demonstrates that this indeed has been fixed. It can be found here:

comment:8 by Simon Charette, 9 years ago

Looks like this hasn't been fixed on Spatialite and Oracle.

comment:9 by Claude Paroz <claude@…>, 9 years ago

In 374c2419e5adef53a643bf69c4753a6bf0c78a98:

Tested that geo aggregates support slicing

Refs #15101. Patch slightly reworked by Claude Paroz.

comment:10 by Claude Paroz, 9 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top