<HTML dir=ltr><HEAD><TITLE>Re: [postgis-devel] Dropped DM (Time) dimension with intersections</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.5626" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText47817 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Paul,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I'm a little confused about your statement. I guess I haven't thought about 3D stuff all that much, but are you saying if you have varying Z of a polygon or line it has no meaning or ambiguous meaning?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>To me its a 2D object in 3D space and if I glue each of those faces together, I could get what would appear to be a volumetric thing - a wireframe if you will. My visualization abilities are kind of weak though but to me something like</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>LINESTRING(1 2 3,3 4 5)</FONT></DIV><FONT face=Arial size=2></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>makes sense and woud represent a line not completely horizontal relative to Z?<BR></DIV></FONT></DIV>
<DIV dir=ltr>Thanks,</DIV>
<DIV dir=ltr>Regina<BR></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR><B>Sent:</B> Tue 10/7/2008 12:59 PM<BR><B>To:</B> PostGIS Development Discussion; PostGIS Users Discussion<BR><B>Subject:</B> Re: [postgis-devel] Dropped DM (Time) dimension with intersections<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Unfortunately, there's no such thing as a 3D polygon, except for<BR>trivial cases (the triangle, the shape with all Z's the same).<BR>Everything else is unclear on how to interpret the enclosed "plane"<BR>(if that is what it is) formed by an irregularly elevated boundary. So<BR>we can store the things, but there's really no decent way to interpret<BR>them in generality. For that we need the real stuff, Surfaces,<BR>volumes, etc.<BR><BR>I think the "low hanging fruit" is probably more the "infrastructural<BR>requirement". We need a 4D index. That will allow us to handle things<BR>like 4D time tracks and point clouds efficiently, and form the<BR>indexing basis for future volumetric objects.<BR><BR>P.<BR><BR>On Tue, Oct 7, 2008 at 9:44 AM, Obe, Regina <robe.dnd@cityofboston.gov> wrote:<BR>> I'm not sure how low hanging the fruit :), but first off would be being able<BR>> to do intersections and indexable ST_DWithin with 3D polygons and<BR>> linestrings and so forth. For example when I place a cable up on a roof I<BR>> need to know if I'm hitting another piece of equipment.<BR>><BR>> Higher fruit - being able to support volumetric geometries. Right now we<BR>> support 2d-3D polygons and lines and you can form wireframes with those, but<BR>> no true volumetric stuff. But then what do I know, I'm just parroting<BR>> things I've heard in whispers and those whispers are getting louder is all<BR>> :)<BR>><BR>> There is still the issue of being able to display 3-D geometries without<BR>> spending a fortune on proprietary stuff which is not a PostGIS issue, but<BR>> has to gain in momentum to make PostGIS 3D more powerful (e.g. uDig for 3D<BR>> or OpenJump for 3D or OpenLayers for 3D?)<BR>><BR>> Thanks,<BR>> Regina<BR>> ________________________________<BR>> From: postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR>> Sent: Tue 10/7/2008 12:30 PM<BR>> To: PostGIS Development Discussion<BR>> Subject: Re: [postgis-devel] Dropped DM (Time) dimension with intersections<BR>><BR>> Perhaps elabourate on what better 3D support would be? There's the<BR>> surface object hanging around. There's the issue of maintaining higher<BR>> dimensional coordinates through lower dimensional transforms (which<BR>> you saw the result of a few days ago). There's elabourating the<BR>> complete set of 3D objects and relationships (gulp).<BR>><BR>> It's not clear to me what is the "low hanging fruit" that will make 3D<BR>> users happiest in the shortest time.<BR>><BR>> P.<BR>><BR>> On Tue, Oct 7, 2008 at 8:54 AM, Obe, Regina <robe.dnd@cityofboston.gov><BR>> wrote:<BR>>> Margie,<BR>>><BR>>> Unfortunately I think the answer is no. Most of the work going on in 1.4<BR>>> is<BR>>> to improve speed of existing functionality and reorganize the source to<BR>>> make<BR>>> it more maintainable.<BR>>><BR>>> Someone please correct me if I am wrong.<BR>>><BR>>> I for one would be very elated if we had better 3D support since CityGML<BR>>> and<BR>>> similar initiatives are becoming more of a hot topic around here.<BR>>><BR>>> Thanks,<BR>>> Regina<BR>>> ________________________________<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<BR>>> Huntington, Margaret (US SSA)<BR>>> Sent: Tuesday, October 07, 2008 11:47 AM<BR>>> To: postgis-devel@postgis.refractions.net<BR>>> Subject: [postgis-devel] Dropped DM (Time) dimension with intersections<BR>>><BR>>> Hello,<BR>>><BR>>> Currently I'm using PostGIS 1.3.3. From past discussions and from<BR>>> testing, both the st_intersection st_extend methods return 2D results with<BR>>> 4D input geometries. As a temporary work-around, I had hoped<BR>>> st_intersection might work with 3DM geometries. (Plan was to interpolate<BR>>> the altitude value within the function call if PostGIS could calculate the<BR>>> time dimension). I found time components are also dropped by<BR>>> st_intersection with 3DM geometries. I abandoned usage of 4D bounding<BR>>> boxes<BR>>> since these too effectively degrade 4D geometries down to 2D geometries<BR>>> (altitude and time are zeroed out).<BR>>><BR>>> polyGeometry geometry;<BR>>><BR>>> bbGeometry geometry;<BR>>><BR>>> intersectionGeometry geometry;<BR>>><BR>>> coorddims smallint;<BR>>><BR>>> -- both polygon and linestring have an expected zmflag value of<BR>>> 1<BR>>><BR>>> polyGeometry := 'SRID=4326;POLYGONM((0 0 0, 0 10 4, 10 10 4, 10<BR>>> 0<BR>>> 0, 0 0 0))'::geometry;<BR>>><BR>>> bbGeometry := 'SRID=4326;LINESTRINGM(0 0 1.5, 10 10<BR>>> 2)'::geometry;<BR>>><BR>>> intersectionGeometry := st_intersection(polyGeometry,<BR>>> bbGeometry);<BR>>><BR>>> -- st_intersection method drops the time dimension; zmflag<BR>>> value<BR>>> of 0<BR>>><BR>>> coorddims := st_zmflag(intersectionGeometry);<BR>>><BR>>> If I were to download the subversion snapshot, the current 1.4 version,<BR>>> might st_intersection work with either 3DM or 4D geometries? Are bounding<BR>>> boxed or st_extend improved for either 3DM or 4D geometries? I had<BR>>> incorporated polygons only as a possible work-around to the bounding box<BR>>> and<BR>>> st_extend 2D limitations.<BR>>><BR>>> Margie<BR>>><BR>>> ________________________________<BR>>><BR>>> The substance of this message, including any attachments, may be<BR>>> confidential, legally privileged and/or exempt from disclosure pursuant to<BR>>> Massachusetts law. It is intended solely for the addressee. If you<BR>>> received<BR>>> this in error, please contact the sender and delete the material from any<BR>>> computer.<BR>>><BR>>> ________________________________<BR>>><BR>>> Help make the earth a greener place. If at all possible resist printing<BR>>> this<BR>>> email and join us in saving paper.<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>> _______________________________________________<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>><BR>> The substance of this message, including any attachments, may be<BR>> confidential, legally privileged and/or exempt from disclosure pursuant to<BR>> Massachusetts law. It is intended solely for the addressee. If you received<BR>> this in error, please contact the sender and delete the material from any<BR>> computer.<BR>><BR>> ________________________________<BR>><BR>> Help make the earth a greener place. If at all possible resist printing this<BR>> email and join us in saving paper.<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>_______________________________________________<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>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>