[postgis-devel] ST_Area, ST_Area2D

[Obe, Regina]

Either works for me as long as they all behave the same. 

I suppose that gives us space to grow to support n-dimensional space :)

R


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, July 18, 2008 3:20 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] ST_Area, ST_Area2D

Optional argument? :)

st_length(geom, [dim])

default is 2d regardless of input, [dim] = 3 allows you to get 3d if
you need it.

P

On Fri, Jul 18, 2008 at 10:27 AM, Obe, Regina
<robe.dnd at cityofboston.gov> wrote:
> Okay so we document all 3 variants or 2 variants (and if 2 which to
keep
> ST_Length2D() or ST_Length())
>
> ST_Length2D(), ST_Length3D()
>
> 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.
>
> But that is inconsistent with our documenting all 3 variants of
Perimeter
> ST_perimeter(geometry)
>
> Returns the 2-dimensional perimeter of the geometry, if it is a
polygon or
> multi-polygon.
>
> ST_perimeter2d(geometry)
>
> Returns the 2-dimensional perimeter of the geometry, if it is a
polygon or
> multi-polygon.
>
> ST_perimeter3d(geometry)
>
> Returns the 3-dimensional perimeter of the geometry, if it is a
polygon or
> multi-polygon.
>
>
>
>
>
> ________________________________
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul
Ramsey
> Sent: Fri 7/18/2008 11:06 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] ST_Area, ST_Area2D
>
> length3d should return a different result for a 3d line than
> lenght2d... and we do need both variants, since sometimes you want the
> 2d legth of a 3d line.
>
> P.
>
> On Fri, Jul 18, 2008 at 7:55 AM, Obe, Regina
<robe.dnd at cityofboston.gov>
> wrote:
>> Paul,
>> Ditto for these too?  ESRI and IBM just refer to this as ST_Length
>> --Docs have ST_Length2D and 3D but no ST_Length
>>
>> ST_length2d(geometry)
>>
>>    Returns the 2-dimensional length of the geometry if it is a
>> linestring or multi-linestring.
>>
>> Just replace with ST_Length()?
>> Both ST_Length() and ST_Length2d() map to -
>> LWGEOM_length2d_linestring
>>
>> Now ST_Length3D() maps to LWGEOM_length_linestring
>>
>> Which on closer tests - gives me the same answer as ST_Length() for a
>> 2-d string.
>>
>> Is there a reason why we can't just have a single documented
>>
>> ST_Length and state it works for both 2D and 3D strings?  and in
future
>> versions just have all 3 map to LWGEOM_length_linestring
>>
>> and deprecate the 2D and 3D names?
>>
>> 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: Friday, July 18, 2008 10:35 AM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] ST_Area, ST_Area2D
>>
>> Undocument it, and note that it is deliberately undocumented in the
>> .sql.in file, so we don't go and re-document it in the future.
>>
>> On Fri, Jul 18, 2008 at 5:36 AM, Obe, Regina
<robe.dnd at cityofboston.gov>
>> wrote:
>>> Can I scrap ST_Area2D from docs and just replace with ST_Area? or is
>>> ST_Area2D really the preferred name?  They both map to
>>> LWGEOM_area_polygon, but
>>> the docs list the ST_Area2D one which seems a bit more verbose and
>>> unconventional.
>>>
>>> Both IBM and ESRI on quick search just call it ST_Area
>>> IBM -
>>>
>>
publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.spatia
>>> l.doc/rsbp4034.html
>>>
>>> and Esri
>> webhelp.esri.com/arcgisserver/9.3/java/geodatabases/st_area.htm
>>>
>>>
>>>
>>> -----------------------------------------
>>> The substance of this message, including any attachments, may be
>>> confidential, legally privileged and/or exempt from disclosure
>>> pursuant to Massachusetts law. It is intended
>>> solely for the addressee. If you received this in error, please
>>> contact the sender and delete the material from any computer.
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel