[postgis-users] [postgis-devel] Geog/Geom Hack

Paragon Corporation lr at pcorp.us
Fri Oct 30 21:15:00 PDT 2009


Paul,
For what its worth, here is another reason why I don't like this idea and I
think we should at least think about its ramifications more so should put it
off for consideration until 2.0.

In geometry processing, its common practice to apply a lot of functions in
succession

process1(process2(process3(geometry/geography)

With your hackish approach -- the unsuspecting novice user will be incurring
a lot of transformation rounding errors with each process

The advanced user, won't know if this is okay or not -- because they can't
tell by looking at the function call the hidden transformations going on.  

If these did not exist, they would transform once before the processes and
once after) and incurr much less penalty 

But if they both exist, they will treat them as being on equal footing

ST_Buffer(geometry)  and ST_Buffer(geography)


So your approach while well-meaning gives a questionable benefit to novices
and is putting experienced users at a disadvantage.

Thanks,
Regina 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paragon
Corporation
Sent: Friday, October 30, 2009 11:54 PM
To: 'PostGIS Development Discussion'
Cc: 'PostGIS Users Discussion'
Subject: Re: [postgis-devel] Geog/Geom Hack

Paul,
I suppose we can't just put this decision off till 2.0.  Isn't this a bit of
scope creep?  I'm not absolutely sure which way is better, but I know the
cost of rolling back the change is more.

If you are going to do this, how many functions are you planning to do this
for?

I'm cc'ing the postgis users group too to get more of an opinion on this
topic.

So the question is it it a good idea to introduce a hack that transforms a
geography into what we call BestSRID to perform geometry operations on and
then transform back.  My concern is that this is a silent operation that
gives the impression that these functions are natively done in spheroid
space just for the benefit of  catering to less technical users.

http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541

So you can't really tell by looking the penalty

Main examples of this as shown for ST_Buffer

CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography) 
530         RETURNS integer 
531         AS 'MODULE_PATHNAME','geography_bestsrid' 
532         LANGUAGE 'C' IMMUTABLE STRICT; 
533
534 -- Availability: 1.5.0
535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography) 
536         RETURNS integer 
537         AS 'SELECT _ST_BestSRID($1,$1)' 
538         LANGUAGE 'SQL' IMMUTABLE STRICT; 
539
540 -- Availability: 1.5.0
541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8) 
542         RETURNS geography 
543         AS 'SELECT
geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
_ST_BestSRID($1)), $2), 4326))' 
544         LANGUAGE 'SQL' IMMUTABLE STRICT; 
545 



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 11:07 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

We're going to have to agree to disagree on this one, Regina. Catering to
the less technical users is what this exercise is all about, to my mind, and
that includes allowing easy flipping into geometry for calculations that
aren't supported in geography yet. Oracle does this too.

What do other folks think?

P.

On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation <lr at pcorp.us> wrote:
> Paul,
> Hmm when I am comparing distance of two geometries in different 
> spatial refs which I do a lot.
>
> I still don't like the hack even if you disregard the above or if you 
> must hack -- don't give it the same name as the non-hacked functions.
>
> the whole idea of picking BestSRID for a person to cater to less 
> technical users I find extremely annoying as I can think of 20 
> "BestSRID" depending on what I am doing.  If they get to that level of 
> sophistication, I would rather have them think a little more  and 
> understand the implications of those decisions.
>
> We must learn to crawl before we can learn to walk,because walking 
> without understanding will just get you into trouble in the long run.
>
>
>  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 9:47 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> 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
>>
> _______________________________________________
> 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





More information about the postgis-users mailing list