[postgis-devel] Geog/Geom Hack

[Paragon Corporation]

Paul,
I can put a functional geography index on can't I and take advantage of
geography index bindings?

Lets say I have a large network of tables broken out by region so I know a
specific table has one srid.

For many queries, I may go to that table directly or if I'm doing single
geometry processing, really don't care what srid as long as its in utm or
whatever - so I can use the full power of GEOS.

For my across the board distance checks and so forth, I would want to use
geography and I could use a geography index if I put a functional geography
index on my geometry correct?  Though that needs some more testing.


So in short if 90% of my workload involves geometry processing, I will want
to keep my data in geometry

But the 10% I would want to convert to geography on the fly.

Thanks,
Regina 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, October 30, 2009 8:34 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

I'm not sure I understand why you would ever convert a geometry to a
geography as part of a query on a geometry table. I fully expect geography
to be used as a storage type, because of the utility of having the correct
spherical indexes, which are not available when you're just converting in
via a cast. Since there's no functions available on geography that are not
already available on geometry, why would you ever do a geometry->geography
cast unless you are (a) testing geography or (b) bulk converting a table
into geography for storage in that type.

P.



On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr at pcorp.us> wrote:
> Paul,
> I would rather you didn't for 2 reasons
>
> 1) I'm lazy and for each of these things we'd have to apply the text 
> additional function proto hack to prevent from it breaking geometry.  
> which we will probably end up taking out anyway.
>
> 2) I don't like the hiddenness of it since it becomes especially 
> annoying if you have your native in geometry and you are converting to 
> geography for a special usecase, then you end up with a slower 
> implementation
>
> as you would really end up doing accidentally
>
> geometry -> geography -> geometry ->operation (and why do I want my 
> calcs done in UTM?)
>
> Instead of the more efficient
>
> geometry -> operation
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of 
> Paul Ramsey
> Sent: Friday, October 30, 2009 8:16 PM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Geog/Geom Hack
>
> I'm interested to know what the general opinion is of the trick I've 
> used on
> ST_Buffer(geography):
>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
> #L541
>
> I ask because I could apply the same idea to the larger suite of OGC 
> SFSQL predicates before release. Is half-a-loaf better than no loaf in
this case?
> (Note that there will be failure cases for really large geometry, like 
> a polygon of "Asia" or "Russia" that have polygons over the dateline.)
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel