<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18828"></meta>
<meta name="SKYPE_FRAMEID" content="HBROAMAKDT"></meta>
<meta id="skype_v3_tb_marker_id" name="SKYPE_PARSING_HAS_FINISHED" content="metacontent"></meta>
</head>
<body>
<div align="left">Hallo</div>
<div align="left"> </div>
<div align="left">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.</div>
<div align="left">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.</div>
<div align="left"> </div>
<div align="left">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:</div>
<div align="left">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.</div>
<div align="left"> </div>
<div align="left">the t would be independent of geography-geometry in semantics and just indicate that it is a lower-precision variant. I fit was commonly used it would work as a warning to experienced users.</div>
<div align="left"> </div>
<div align="left">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 <span class="refentrytitle">ST_MinimumBoundingCircle and id makes a big difference to do :</span></div>
<div align="left"><span class="refentrytitle">st_max_distance(st_convexhull(the_geom)) instead of just <span class="refentrytitle">st_max_distance(the_geom). </span></span></div>
<div align="left"><span class="refentrytitle"><span class="refentrytitle">The question is: Should that be put in the sql-function?</span></span></div>
<div align="left"><span class="refentrytitle"><span class="refentrytitle">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.</span></span></div>
<div align="left"><span class="refentrytitle"><span class="refentrytitle"> </span></span></div>
<div align="left"><span class="refentrytitle"><span class="refentrytitle">/Nicklas</span></span></div>
<div align="left"> </div>
<div align="left"><br />
2009-10-31 Paul Ramsey wrote:<br />
<br />
I still think I'm right :) Honestly, I've got to a lot of trouble to<br />
>make this stuff for newbies, and I don't think "learn how it works" is<br />
>the right answer for them. They had that option before, but taking GIS<br />
>101 is not an option for these people, they need something that "just<br />
>works". It's easier to teach the experienced people the pitfalls than<br />
>the inexperienced people the basics.<br />
><br />
>BTW, I just upgraded distance_sphere and distance_spheroid to be as<br />
>powerful (handling point/line/polygon) as the geography variants,<br />
>removing excuses for transforming geometries into geographies for<br />
>processing purposes.<br />
><br />
>P.<br />
><br />
>On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation
<lr@pcorp.us></lr@pcorp.us>wrote:<br />
>> Paul,<br />
>> For what its worth, here is another reason why I don't like this idea and I<br />
>> think we should at least think about its ramifications more so should put it<br />
>> off for consideration until 2.0.<br />
>><br />
>> In geometry processing, its common practice to apply a lot of functions in<br />
>> succession<br />
>><br />
>> process1(process2(process3(geometry/geography)<br />
>><br />
>> With your hackish approach -- the unsuspecting novice user will be incurring<br />
>> a lot of transformation rounding errors with each process<br />
>><br />
>> The advanced user, won't know if this is okay or not -- because they can't<br />
>> tell by looking at the function call the hidden transformations going on.<br />
>><br />
>> If these did not exist, they would transform once before the processes and<br />
>> once after) and incurr much less penalty<br />
>><br />
>> But if they both exist, they will treat them as being on equal footing<br />
>><br />
>> ST_Buffer(geometry) and ST_Buffer(geography)<br />
>><br />
>><br />
>> So your approach while well-meaning gives a questionable benefit to novices<br />
>> and is putting experienced users at a disadvantage.<br />
>><br />
>> Thanks,<br />
>> Regina<br />
>><br />
>> -----Original Message-----<br />
>> From: postgis-devel-bounces@postgis.refractions.net<br />
>> [mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf Of Paragon<br />
>> Corporation<br />
>> Sent: Friday, October 30, 2009 11:54 PM<br />
>> To: 'PostGIS Development Discussion'<br />
>> Cc: 'PostGIS Users Discussion'<br />
>> Subject: Re: [postgis-devel] Geog/Geom Hack<br />
>><br />
>> Paul,<br />
>> I suppose we can't just put this decision off till 2.0. Isn't this a bit of<br />
>> scope creep? I'm not absolutely sure which way is better, but I know the<br />
>> cost of rolling back the change is more.<br />
>><br />
>> If you are going to do this, how many functions are you planning to do this<br />
>> for?<br />
>><br />
>> I'm cc'ing the postgis users group too to get more of an opinion on this<br />
>> topic.<br />
>><br />
>> So the question is it it a good idea to introduce a hack that transforms a<br />
>> geography into what we call BestSRID to perform geometry operations on and<br />
>> then transform back. My concern is that this is a silent operation that<br />
>> gives the impression that these functions are natively done in spheroid<br />
>> space just for the benefit of catering to less technical users.<br />
>><br />
>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541<br />
>><br />
>> So you can't really tell by looking the penalty<br />
>><br />
>> Main examples of this as shown for ST_Buffer<br />
>><br />
>> CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)<br />
>> 530 RETURNS integer<br />
>> 531 AS 'MODULE_PATHNAME','geography_bestsrid'<br />
>> 532 LANGUAGE 'C' IMMUTABLE STRICT;<br />
>> 533<br />
>> 534 -- Availability: 1.5.0<br />
>> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)<br />
>> 536 RETURNS integer<br />
>> 537 AS 'SELECT _ST_BestSRID($1,$1)'<br />
>> 538 LANGUAGE 'SQL' IMMUTABLE STRICT;<br />
>> 539<br />
>> 540 -- Availability: 1.5.0<br />
>> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)<br />
>> 542 RETURNS geography<br />
>> 543 AS 'SELECT<br />
>> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),<br />
>> _ST_BestSRID($1)), $2), 4326))'<br />
>> 544 LANGUAGE 'SQL' IMMUTABLE STRICT;<br />
>> 545<br />
>><br />
>><br />
>><br />
>> Thanks,<br />
>> Regina<br />
>><br />
>> -----Original Message-----<br />
>> From: postgis-devel-bounces@postgis.refractions.net<br />
>> [mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf Of Paul<br />
>> Ramsey<br />
>> Sent: Friday, October 30, 2009 11:07 PM<br />
>> To: PostGIS Development Discussion<br />
>> Subject: Re: [postgis-devel] Geog/Geom Hack<br />
>><br />
>> We're going to have to agree to disagree on this one, Regina. Catering to<br />
>> the less technical users is what this exercise is all about, to my mind, and<br />
>> that includes allowing easy flipping into geometry for calculations that<br />
>> aren't supported in geography yet. Oracle does this too.<br />
>><br />
>> What do other folks think?<br />
>><br />
>> P.<br />
>><br />
>> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation
<lr@pcorp.us></lr@pcorp.us>wrote:<br />
>>> Paul,<br />
>>> Hmm when I am comparing distance of two geometries in different<br />
>>> spatial refs which I do a lot.<br />
>>><br />
>>> I still don't like the hack even if you disregard the above or if you<br />
>>> must hack -- don't give it the same name as the non-hacked functions.<br />
>>><br />
>>> the whole idea of picking BestSRID for a person to cater to less<br />
>>> technical users I find extremely annoying as I can think of 20<br />
>>> "BestSRID" depending on what I am doing. If they get to that level of<br />
>>> sophistication, I would rather have them think a little more and<br />
>>> understand the implications of those decisions.<br />
>>><br />
>>> We must learn to crawl before we can learn to walk,because walking<br />
>>> without understanding will just get you into trouble in the long run.<br />
>>><br />
>>><br />
>>> Thanks,<br />
>>> Regina<br />
>>><br />
>>> -----Original Message-----<br />
>>> From: postgis-devel-bounces@postgis.refractions.net<br />
>>> [mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf Of<br />
>>> Paul Ramsey<br />
>>> Sent: Friday, October 30, 2009 9:47 PM<br />
>>> To: PostGIS Development Discussion<br />
>>> Subject: Re: [postgis-devel] Geog/Geom Hack<br />
>>><br />
>>> You *can*, but I strongly doubt you *will*. Because there's nothing in<br />
>>> geography that isn't already in geometry. So you as a primary geometry<br />
>>> user are going to have no working need to cast things to geography.<br />
>>><br />
>>> On the other hand, the very first question from users of geography<br />
>>> will be "how can I access
<geometry N function></geometry>?" So having a<br />
>>> relatively full set of functions already available in geography makes<br />
>>> sense to me, even if they are hacked in with a planar trick.<br />
>>><br />
>>> P.<br />
>>><br />
>>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation
<lr@pcorp.us></lr@pcorp.us>wrote:<br />
>>>> Paul,<br />
>>>> I can put a functional geography index on can't I and take advantage<br />
>>>> of geography index bindings?<br />
>>>><br />
>>>> Lets say I have a large network of tables broken out by region so I<br />
>>>> know a specific table has one srid.<br />
>>>><br />
>>>> For many queries, I may go to that table directly or if I'm doing<br />
>>>> single geometry processing, really don't care what srid as long as<br />
>>>> its in utm or whatever - so I can use the full power of GEOS.<br />
>>>><br />
>>>> For my across the board distance checks and so forth, I would want to<br />
>>>> use geography and I could use a geography index if I put a functional<br />
>>>> geography index on my geometry correct? Though that needs some more<br />
>>> testing.<br />
>>>><br />
>>>><br />
>>>> So in short if 90% of my workload involves geometry processing, I<br />
>>>> will want to keep my data in geometry<br />
>>>><br />
>>>> But the 10% I would want to convert to geography on the fly.<br />
>>>><br />
>>>> Thanks,<br />
>>>> Regina<br />
>>>><br />
>>>> -----Original Message-----<br />
>>>> From: postgis-devel-bounces@postgis.refractions.net<br />
>>>> [mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf Of<br />
>>>> Paul Ramsey<br />
>>>> Sent: Friday, October 30, 2009 8:34 PM<br />
>>>> To: PostGIS Development Discussion<br />
>>>> Subject: Re: [postgis-devel] Geog/Geom Hack<br />
>>>><br />
>>>> I'm not sure I understand why you would ever convert a geometry to a<br />
>>>> geography as part of a query on a geometry table. I fully expect<br />
>>>> geography to be used as a storage type, because of the utility of<br />
>>>> having the correct spherical indexes, which are not available when<br />
>>>> you're just converting in via a cast. Since there's no functions<br />
>>>> available on geography that are not already available on geometry,<br />
>>>> why would you ever do a geometry->geography cast unless you are (a)<br />
>>>> testing geography or (b) bulk converting a table into geography for<br />
>>> storage in that type.<br />
>>>><br />
>>>> P.<br />
>>>><br />
>>>><br />
>>>><br />
>>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation
<lr@pcorp.us></lr@pcorp.us>wrote:<br />
>>>>> Paul,<br />
>>>>> I would rather you didn't for 2 reasons<br />
>>>>><br />
>>>>> 1) I'm lazy and for each of these things we'd have to apply the text<br />
>>>>> additional function proto hack to prevent from it breaking geometry.<br />
>>>>> which we will probably end up taking out anyway.<br />
>>>>><br />
>>>>> 2) I don't like the hiddenness of it since it becomes especially<br />
>>>>> annoying if you have your native in geometry and you are converting<br />
>>>>> to geography for a special usecase, then you end up with a slower<br />
>>>>> implementation<br />
>>>>><br />
>>>>> as you would really end up doing accidentally<br />
>>>>><br />
>>>>> geometry -> geography -> geometry ->operation (and why do I want my<br />
>>>>> calcs done in UTM?)<br />
>>>>><br />
>>>>> Instead of the more efficient<br />
>>>>><br />
>>>>> geometry -> operation<br />
>>>>><br />
>>>>> Thanks,<br />
>>>>> Regina<br />
>>>>><br />
>>>>> -----Original Message-----<br />
>>>>> From: postgis-devel-bounces@postgis.refractions.net<br />
>>>>> [mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf Of<br />
>>>>> Paul Ramsey<br />
>>>>> Sent: Friday, October 30, 2009 8:16 PM<br />
>>>>> To: PostGIS Development Discussion<br />
>>>>> Subject: [postgis-devel] Geog/Geom Hack<br />
>>>>><br />
>>>>> I'm interested to know what the general opinion is of the trick I've<br />
>>>>> used on<br />
>>>>> ST_Buffer(geography):<br />
>>>>><br />
>>>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.<br />
>>>>> c<br />
>>>>> #L541<br />
>>>>><br />
>>>>> I ask because I could apply the same idea to the larger suite of OGC<br />
>>>>> SFSQL predicates before release. Is half-a-loaf better than no loaf<br />
>>>>> in<br />
>>>> this case?<br />
>>>>> (Note that there will be failure cases for really large geometry,<br />
>>>>> like a polygon of "Asia" or "Russia" that have polygons over the<br />
>>>>> dateline.)<br />
>>>>><br />
>>>>> P.<br />
>>>>> _______________________________________________<br />
>>>>> postgis-devel mailing list<br />
>>>>> postgis-devel@postgis.refractions.net<br />
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>>><br />
>>>>><br />
>>>>><br />
>>>>> _______________________________________________<br />
>>>>> postgis-devel mailing list<br />
>>>>> postgis-devel@postgis.refractions.net<br />
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>>><br />
>>>> _______________________________________________<br />
>>>> postgis-devel mailing list<br />
>>>> postgis-devel@postgis.refractions.net<br />
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>><br />
>>>><br />
>>>><br />
>>>> _______________________________________________<br />
>>>> postgis-devel mailing list<br />
>>>> postgis-devel@postgis.refractions.net<br />
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>><br />
>>> _______________________________________________<br />
>>> postgis-devel mailing list<br />
>>> postgis-devel@postgis.refractions.net<br />
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>><br />
>>><br />
>>> _______________________________________________<br />
>>> postgis-devel mailing list<br />
>>> postgis-devel@postgis.refractions.net<br />
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> postgis-devel@postgis.refractions.net<br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> postgis-devel@postgis.refractions.net<br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> postgis-devel@postgis.refractions.net<br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
>postgis-devel@postgis.refractions.net<br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>