[postgis-devel] Geog/Geom Hack

[Paul Ramsey]

You *can*, but I strongly doubt you *will*. Because there's nothing in
geography that isn't already in geometry. So you as a primary geometry
user are going to have no working need to cast things to geography.

On the other hand, the very first question from users of geography
will be "how can I access <geometry function N>?" So having a
relatively full set of functions already available in geography makes
sense to me, even if they are hacked in with a planar trick.

P.

On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr at pcorp.us> wrote:
> 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
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>