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

[Paragon Corporation]

The more that I'm thinking about it, I'm actually okay with the 

st_buffer(geom, rad, params)

To support the backward compatibility, we could just have the function
handle the special case when someone only passed in a number as a string
like '10'.  In the buffer function.  So that takes care of the backward
compatibility with people mis relying on autocasting.

Yah the array thing looks pretty ugly.  I was thinking about using a custom
buffer_style_type type, but that doesn't look much better if you want to do
it in a single sql statement without a help style creator function.

But Paul's suggestion (if I read it correctly), of pulling the plug on the 

St_buffer(geom,rad, quadsegs)

To me sounds like a bad idea.  It doesn't only break backward compatibility,
but makes what I consider the more common use case more difficult to write.


Now I have to write something goofy like
ST_Buffer(geom,10, 'quad_segs=10')

Everytime I want to control the more true to lifeness of my buffer.

Mark my point about the SQL Server and Oracle exampels was not so much
keeping compatibility (I mean we are far from that anyway) with those, but
that tolerance/quad segments is something that most users are familiar with
when using buffers -- and to hide that in a params just makes the quad segs
thing much less useable.

Thanks,
Regina



 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of strk
Sent: Sunday, June 21, 2009 6:12 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Specifying end cap and join styles Buffer op

On Sun, Jun 21, 2009 at 11:02:37PM +0100, Mark Cave-Ayland wrote:

> String parsing seems quite horrible in this day and age; any reason we 
> can't use PostgreSQL arrays to pass in the information instead? I 
> really don't care too much about Oracle compatibility since PostGIS as 
> a project is heading more towards SQL-MM.

Paul and me excercised a bit in inputing SQL and found arrays being less
comfortable than a plain string.

Compare:

	st_buffer(geom, 10, 'join=bevel endcap=flat limit=10');
with:
	st_buffer(geom, 10, '{{"join",
bevel"},{"endcap","flat"},{"limit","10"}}');

(pretty sure the first one I typed it correctly, should check for the
second)

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel