I would say that ST_OffsetCurve(geom,right/left) is the way to go.<br><br>Two functions would be more difficult to handle. Higher maintenance, bigger codebase/etc.<br><br>Or they are just wrappers? even so, it's two instead of one.<br>

<br>George<br><br><div class="gmail_quote">On Sun, Aug 8, 2010 at 7:26 PM, strk <span dir="ltr"><<a href="mailto:strk@keybit.net">strk@keybit.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Fri, Aug 06, 2010 at 02:14:42PM +0200, Stephan Holl wrote:<br>
> Dear PostGIS-devs,<br>
><br>
> I am reading the issue #413 very closely because this function is a<br>
> needed feature for my current application.<br>
><br>
> Is there any chance to get more information about a potential include<br>
> into SVN and an integration in new upcoming versions?<br>
<br>
</div>It looks like the ticket hung on naming issue:<br>
do people prefer ST_OffsetCurveRight/ST_OffsetCurveLeft<br>
or ST_OffsetCurve(geom, ['right'|'left']) ?<br>
<br>
The patch implements the latter.<br>
<br>
This is important, as the testcase and documentation will need to<br>
be produced using the agreed-on syntax...<br>
<br>
On a side-note, the C-level functions should likely have an ST_<br>
prefix too, and be CamelCased as documented..<br>
<br>
--strk;<br>
<br>
  ()   Free GIS & Flash consultant/developer<br>
  /\   <a href="http://strk.keybit.net/services.html" target="_blank">http://strk.keybit.net/services.html</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>George R. C. Silva<br><br>Desenvolvimento em GIS<br><a href="http://blog.geoprocessamento.net">http://blog.geoprocessamento.net</a><br>