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

Paul Ramsey pramsey at cleverelephant.ca
Fri Jun 19 14:28:46 PDT 2009


The non-ST_ prefixed functions are there for *legacy* purposes, so do
not add new ones or alter the old ones.

P

On Fri, Jun 19, 2009 at 2:20 PM, strk<strk at keybit.net> wrote:
> Hi all,
> I'm working on exposing end cap and join style control
> to the Buffer operation of postgis.
>
> A question for you is: what to do with the 'st_' ?
>
> We currently have multiple versions of Buffer and ST_Buffer
> overloaded to accept default arguments.
> I'd need to add more arguments (+1, +2, +3) so 3 more SQL
> signatures. If we keep maintaining ST and ST-free versions
> these will be 6 more SQL functions.
>
> My idea has always been for prefixes to only reflect standard
> operations, so similarly to what happens for ST_GeometryType vs.
> GeometryType (they return different strings) I'd have ST-free
> Buffer allow specifying non-starndard arguments and keep the
> ST-full one forbid that (to avoid mismatch if and when the
> standard will allow for controlling end-cap and join stiles
> and what else [mitre limit]).
>
> Please give me advice on how to proceed as I suspect my idea
> isn't very popular nowadays :)
>
> If you're into the ST just let me know and I'll do the ST version
> only and let alone the ST-free, or vote for both and I'll add all 6
> new functions.
>
> Thanks in advance.
>
> --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
>



More information about the postgis-devel mailing list