[postgis-devel] Geog/Geom Hack

nicklas.aven at jordogskog.no nicklas.aven at jordogskog.no
Sat Oct 31 07:03:52 PDT 2009 

Hallo I can see the points from both of you. I think the most important argument from you Regina is that it is not transparent enough. A skillfull user trying postgis might be disapointed when realizing that the nested functions caused an unnecessary big rounding-error.But if it is obvious that it is a "special" function at least for the experienced user knowing about common function-names I don't think it is a big problem and might work as an easy shortcut at least during the process of learning. As I understand it this could be a solution for using many functions against geography so, why not  note it in the function name like:ST_tBuffer for transformed buffer. Then when time is to introduse a "real" variant of the function they can coexist and it will not change the bahavior inside an application without someone consciously changes the function name and remove the t. the t would be independent of geography-geometry in semantics and just indicate that it is a lower-precisi!
 on variant. I fit was commonly used it would work as a warning to experienced users. I have a similar question about st_max_distance. The function gets very much more effective when ran together with convexhull. I saw the trick in ST_MinimumBoundingCircle and id makes a big difference to do :st_max_distance(st_convexhull(the_geom)) instead of just st_max_distance(the_geom). The question is: Should that be put in the sql-function?My opinion now is that we just tell about it in the documentation and aims at doing that trick internally in C in the future. Maybe together with moving the whole convexhull to postgis-native from geos. It didn't look that impossible fromthe JTS-code. /Nicklas 
2009-10-31 Paul Ramsey wrote:

I still think I'm right :) Honestly, I've got to a lot of trouble to
>make this stuff for newbies, and I don't think "learn how it works" is
>the right answer for them. They had that option before, but taking GIS
>101 is not an option for these people, they need something that "just
>works". It's easier to teach the experienced people the pitfalls than
>the inexperienced people the basics.
>
>BTW, I just upgraded distance_sphere and distance_spheroid to be as
>powerful (handling point/line/polygon) as the geography variants,
>removing excuses for transforming geometries into geographies for
>processing purposes.
>
>P.
>
>On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporationwrote:
>> 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 Corporationwrote:
>>> 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?" 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 Corporationwrote:
>>>> 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 Corporationwrote:
>>>>> 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
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091031/85941386/attachment.html>

More information about the postgis-devel mailing list