[postgis-devel] ST_Buffer in 3D supporting Z

Paragon Corporation lr at pcorp.us
Thu May 3 20:25:01 PDT 2012


Sam,
 
I won't be able to make it to Paris eitehr :(.  I am on the east coast :).
I think just ideas will come out of Paris Sprint.  Nothing will be set in
stone until discussed and voted and even then, I think it would take time to
integrate third party options if that is decided.  So I expect this to be
one of many discussions.
If you are on the East and interested in discussions.  We are having a
Boston OSGEO Code Sprint.  A ways away where there will be a large PostGIS
developer crowd.
 
http://wiki.osgeo.org/wiki/Boston_Code_Sprint_2013#Participation
 
Feel free to sign up of you are planning to come and do some serious PostGIS
development.
 
We haven't set specific dates yet but we are looking at Late January -
March.  Most likely February sometime 2013.
 
As far as tickets go, the best way to get started is to attach patches to
those tickets and we'll try to integrate them in.  If you start submitting
too many quality patches, we may get tired of patching in and ask you to
proverbially sign some papers and become an official member of our team.
 
Thanks,
Regina
http://www.postgis.us
 


  _____  

From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Sam
Hariton
Sent: Thursday, May 03, 2012 11:32 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] ST_Buffer in 3D supporting Z


Regina, 

Thanks.  Unfortunately, I'm not going to make it Paris but next time your on
the east coast I'll try to stop by (apparently I completely missed the event
in DC last month).


Is the Paris Sprint likely to result in a decision about
GEOS/Boost/CGAL/PostGIS core/etc.?  Or is it a longer term discussion than
that?




In the meantime, looking through the ticket list, there's a couple tickets
(#430 and #428) that look interesting and I'd like to make a stab at.
What's the proper etiquette for doing so?


Thanks


 - Sam

On Wed, May 2, 2012 at 4:22 AM, Paragon Corporation <lr at pcorp.us> wrote:



Sam,
 
Sam,
Not to my knowledge.  There are a couple of hurdles we need to jump before
that step.
 
The big one:
 
GEOS is predominantly 2-D engine:  PostGIS buffer and many other functions
piggy -back on that.
 
so the big question is whether to expand GEOS to handle new 3d types thus
deviating more from its JTS roots or use another engine like Boost or CGAL.
The other option is just to build into PostGIS core, but not sure how much
effort is involved there.
 
Olivier is working on much of the 3D stuff and many of the PostGIS core dev
are having a code sprint in Paris.
 
I think there is still space left if you want to chat up with them and you
can make the trip.
 
http://trac.osgeo.org/postgis/wiki/DevWikiEvent
 
Hope that helps,
Regina
http://www.postgis.us
 
 
 


  _____  

From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Sam
Hariton
Sent: Tuesday, May 01, 2012 4:06 PM
To: postgis-devel at postgis.refractions.net
Subject: [postgis-devel] ST_Buffer in 3D supporting Z


Is anyone looking at adding the ability for st_buffer to keep Z coordinates
as well for 3-dimensional spaces?  If so, I'd like to help.

The Postgis 2.0 docs state:  This function ignores the third dimension (z)
and will always give a 2-d buffer even when presented with a 3d-geometry.

Right now 




select st_astext(st_buffer(geomfromEWKT('POINT(0 0 0)'),1));


Generates a flat Polygon/Circle of radius 1 (completely dropping the z
dimension):

 POLYGON((1 0,0.980785280403231 -0.195090322016128,0.923879532511287
-0.382683432365089,0.831469612302546 -0.555570233019602,0.707106781186548
-0.707106781186547,0.555570233019603 -0.831469612302545,0.382683432365091
-0.923879532511286,0.19509032201613 -0.98078528040323,1.61554255216634e-15
-1,-0.195090322016126 -0.980785280403231,-0.382683432365088
-0.923879532511288,-0.555570233019601 -0.831469612302546,-0.707106781186546
-0.707106781186549,-0.831469612302544 -0.555570233019604,-0.923879532511286
-0.382683432365092,-0.98078528040323 -0.195090322016131,-1
-3.23108510433268e-15,-0.980785280403231
0.195090322016125,-0.923879532511288
 0.382683432365086,-0.831469612302547 0.555570233019599,-0.70710678118655
0.707106781186545,-0.555570233019606 0.831469612302543,-0.382683432365094
0.923879532511285,-0.195090322016132 0.98078528040323,-3.73640463187386e-15
1,0.195090322016125 0.980785280403231,0.382683432365087
0.923879532511288,0.5555702330196 0.831469612302547,0.707106781186545
0.70710678118655,0.831469612302544 0.555570233019604,0.923879532511286
0.382683432365092,0.98078528040323 0.19509032201613,1 0))

Whereas, if it had z support it should actually generate a Polyhedral
Surface/Sphere of radius 1 centered on (0 0 0)


 - Sam



_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20120503/64a3223f/attachment.html>


More information about the postgis-devel mailing list