Going beyond the limitations of GeoQuerySet transform

[Aryeh Leib Taurog]

I have been playing with the GeoQuerySet transform method. I wanted a
way to transform the geometry fields on related records as well.

While searching, I ran across this thread [http://groups.google.com/
group/geodjango/browse_thread/thread/dc9ba5422805ae83/
a03afe71e6f167e1], in which is noted that query.transform(srid).extent
() returns extent coordinates in the original projection. The
solution proposed was to convert these to points, transform the
points, and then reconstruct the extent.

I came up with a different solution (though not necessarily better).
I realized I could simplify the python code by setting up a SQL view
in the db which performs the joins and the transforms. Then I could
access my projected data directly through an unmanaged django model.
This also provides a transformed extent directly from the GeoQuerySet.

The tradeoff: this is PostGIS specific and involves custom SQL code,
not terribly djangoesque. It makes sense to me in situations where
there is a lot of python code performing different geometric
operations on a single table or join.

There's good documentation on setting up such a view here
http://postgis.refractions.net/docs/ch04.html#Manual_Register_Spatial_Column

Thoughts anyone?

[Justin Bronn]

Aryeh Leib Taurog wrote:
> I came up with a different solution (though not necessarily better).
> I realized I could simplify the python code by setting up a SQL view
> in the db which performs the joins and the transforms. Then I could
> access my projected data directly through an unmanaged django model.
> This also provides a transformed extent directly from the GeoQuerySet.
>
> The tradeoff: this is PostGIS specific and involves custom SQL code,
> not terribly djangoesque. It makes sense to me in situations where
> there is a lot of python code performing different geometric
> operations on a single table or join.
>
> There's good documentation on setting up such a view here
> http://postgis.refractions.net/docs/ch04.html#Manual_Register_Spatial_Column
>
> Thoughts anyone?

Putting the transform in a view and querying on that is a great idea,
because it allows any further operations (.transform().distance()...) to
work with the transformed data -- as is intuitive. This would be
especially useful for distance queries, allowing geographic coordinate
system users to transform and have full-access to the full capabilities
of distance queries (a nice stop-gap measure until geography support in
PostGIS 1.5). I toyed with this idea a bit when implementing, but it
was just too much effort to get it to work.

While Django's support for subqueries has greatly improved since 1.0, it
still takes some effort to get the `extra(select=...)` right. I'm
adding a "recipes" section to the documentation, and a snippet of doing
something cool with this technique would definitely be worth including.

-Justin