<HTML dir=ltr><HEAD><TITLE>Re: [postgis-devel] ST_Area, ST_Area2D</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.5583" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Okay so we document all 3 variants or 2 variants (and if 2 which to keep ST_Length2D() or ST_Length())</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>ST_Length2D(), ST_Length3D()</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Almost seems as if ST_length() should return 2D length for a 2D line and 3D length for a 3d line (which would suggest mapping it to the ST_Length3D(), but I guess that may violate OGC specs but all docs I have read seem vague on the matter. We don't even have these listed as OGC compliant but all Spatial Dbs seem to have it but don't seem to discuss distinction between 2D and 3D). Although its not documented at all so I suppose we can leave as such.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>But that is inconsistent with our documenting all 3 variants of Perimeter</FONT></DIV>
<DIV dir=ltr>
<DT><SPAN class=term>ST_perimeter(geometry)</SPAN></DT>
<DD>
<P>Returns the 2-dimensional perimeter of the geometry, if it is a polygon or multi-polygon.</P></DD>
<DT><SPAN class=term>ST_perimeter2d(geometry)</SPAN></DT>
<DD>
<P>Returns the 2-dimensional perimeter of the geometry, if it is a polygon or multi-polygon.</P></DD>
<DT><SPAN class=term>ST_perimeter3d(geometry)</SPAN></DT>
<DD>
<P>Returns the 3-dimensional perimeter of the geometry, if it is a polygon or multi-polygon.</P></DD></DIV>
<P dir=ltr> </P>
<DIV dir=ltr>
<DD>
<P> </P></DD></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR><B>Sent:</B> Fri 7/18/2008 11:06 AM<BR><B>To:</B> PostGIS Development Discussion<BR><B>Subject:</B> Re: [postgis-devel] ST_Area, ST_Area2D<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>length3d should return a different result for a 3d line than<BR>lenght2d... and we do need both variants, since sometimes you want the<BR>2d legth of a 3d line.<BR><BR>P.<BR><BR>On Fri, Jul 18, 2008 at 7:55 AM, Obe, Regina <robe.dnd@cityofboston.gov> wrote:<BR>> Paul,<BR>> Ditto for these too? ESRI and IBM just refer to this as ST_Length<BR>> --Docs have ST_Length2D and 3D but no ST_Length<BR>><BR>> ST_length2d(geometry)<BR>><BR>> Returns the 2-dimensional length of the geometry if it is a<BR>> linestring or multi-linestring.<BR>><BR>> Just replace with ST_Length()?<BR>> Both ST_Length() and ST_Length2d() map to -<BR>> LWGEOM_length2d_linestring<BR>><BR>> Now ST_Length3D() maps to LWGEOM_length_linestring<BR>><BR>> Which on closer tests - gives me the same answer as ST_Length() for a<BR>> 2-d string.<BR>><BR>> Is there a reason why we can't just have a single documented<BR>><BR>> ST_Length and state it works for both 2D and 3D strings? and in future<BR>> versions just have all 3 map to LWGEOM_length_linestring<BR>><BR>> and deprecate the 2D and 3D names?<BR>><BR>> Thanks,<BR>> Regina<BR>><BR>><BR>><BR>> -----Original Message-----<BR>> From: postgis-devel-bounces@postgis.refractions.net<BR>> [<A href="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</A>] On Behalf Of Paul<BR>> Ramsey<BR>> Sent: Friday, July 18, 2008 10:35 AM<BR>> To: PostGIS Development Discussion<BR>> Subject: Re: [postgis-devel] ST_Area, ST_Area2D<BR>><BR>> Undocument it, and note that it is deliberately undocumented in the<BR>> .sql.in file, so we don't go and re-document it in the future.<BR>><BR>> On Fri, Jul 18, 2008 at 5:36 AM, Obe, Regina <robe.dnd@cityofboston.gov><BR>> wrote:<BR>>> Can I scrap ST_Area2D from docs and just replace with ST_Area? or is<BR>>> ST_Area2D really the preferred name? They both map to<BR>>> LWGEOM_area_polygon, but<BR>>> the docs list the ST_Area2D one which seems a bit more verbose and<BR>>> unconventional.<BR>>><BR>>> Both IBM and ESRI on quick search just call it ST_Area<BR>>> IBM -<BR>>><BR>> publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.spatia<BR>>> l.doc/rsbp4034.html<BR>>><BR>>> and Esri<BR>> webhelp.esri.com/arcgisserver/9.3/java/geodatabases/st_area.htm<BR>>><BR>>><BR>>><BR>>> -----------------------------------------<BR>>> The substance of this message, including any attachments, may be<BR>>> confidential, legally privileged and/or exempt from disclosure<BR>>> pursuant to Massachusetts law. It is intended<BR>>> solely for the addressee. If you received this in error, please<BR>>> contact the sender and delete the material from any computer.<BR>>><BR>>> _______________________________________________<BR>>> postgis-devel mailing list<BR>>> postgis-devel@postgis.refractions.net<BR>>> <A href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>>><BR>> _______________________________________________<BR>> postgis-devel mailing list<BR>> postgis-devel@postgis.refractions.net<BR>> <A href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>> _______________________________________________<BR>> postgis-devel mailing list<BR>> postgis-devel@postgis.refractions.net<BR>> <A href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>><BR>_______________________________________________<BR>postgis-devel mailing list<BR>postgis-devel@postgis.refractions.net<BR><A href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR></FONT></P></DIV></BODY></HTML>