Geography needs an extent aggregate function

[robe]

I guess its too late to squeeze this in for 1.5.0? But I think we really need an Extent function for Geography.

Just noticed the Add Datastore feature doesn't work out of the box with geography because its trying to call Extent on it (well that's the complaint I get out of the bat). I don't use that mode much anyway so I personally don't care aside from the effect on newbie user experience.

Which brings up the other question that we really need to get the word out with 3rd party tools to switch to using the ST_ version of the functions if we hope to ever bury them. I guess that is a story for another day.

[robe]

Oops for clarity. The add Data Store Layer of OpenJump. I was comparing what tools know what to do with geography without any change.

[mcayland]

Hmmmm I'm sure this was brought up in previous discussions, but yeah I'd say this is something we need for a 1.5 release as ST_Extent() is one of first functions an application will run when it opens a layer.

[pramsey]

And after ST_Extent, what's the next function that's going to be called? And after that? Extent is very ill-defined on the sphere. Think about a pole-encircling polygon or a date-line traversing linestring. What's the proper extent? How is it interpreted? If you want a half-assed extent, then call ST_Extent(thecolumn::geometry), right?

[robe]

Okay that answers that question. That's why I put it in the future. I unlike Mark don't have quite a sense of urgency. Still experimenting with what functions each tool taps into, so my objective is to see how far geography can go without requiring change to underlying desktop/web tools.

Hmm I think we need an ST_Transform (which returns a geometry). But yes I was thinking a half-assed extent :).

[robe]

Milestone renamed