[postgis-devel] Specifying end cap and join styles Buffer op

[Paragon Corporation]

Paul,

So are you thinking of getting rid of the ST_Buffer(geom, radius, quadsegs)?

I know I use that a lot and to me its not really quite the same as the param
argstuff.  Because quadsegs is used for true buffering where you need a more
precise buffer than the default and I don't think of the params as being for
true buffering. Well not the way most people I know think about buffering
anyway. 

I could be wrong though.  I guess most people probably just happily use the
virgin buffer and don't think much about quadsegs.  

Keep in mind though that both Oracle and SQL Server treat tolerance as more
important 

As your link demonstrates 
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_objgeom.h
tm#i856140  (tolerance is so important it has its own slot)

SDO_GEOM.SDO_BUFFER(

     geom IN SDO_GEOMETRY,

     dist IN NUMBER,

     tol IN NUMBER

     [, params IN VARCHAR2]

     ) RETURN SDO_GEOMETRY;


SQL Server's BufferWithTolerance
http://msdn.microsoft.com/en-us/library/bb933892.aspx  (has its own slot)

BufferWithTolerance ( distance, tolerance, relative )



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: Sunday, June 21, 2009 1:31 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Specifying end cap and join styles Buffer op

On Sun, Jun 21, 2009 at 4:23 AM, strk <strk at keybit.net> wrote:

> Also, I agree with Regina about keeping quadSegs and add the params as 
> fourth arg.

Why? this seems like a chance to clean up the buffer API a little, and I
think quadSegs is just as much an "optional, unordered" parameter as the
stuff that will be hidden in the paramstring.

P
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel