[postgis-devel] Dropped DM (Time) dimension with intersections

[Paul Ramsey]

LINESTRING and POINT have clear semantics in 3D.  POLYGON does not
(except for the trivial cases).

POLYGON(-1 0 -1, 0 1 1, 1 0 -1, 0 -1 1, -1 0 -1)

What is the z-value at POINT(0 0) ?

Paul

On Tue, Oct 7, 2008 at 10:31 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> Paul,
>
> 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?
>
> 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
>
> LINESTRING(1 2 3,3 4 5)
>
> makes sense and woud represent a line not completely horizontal relative to
> Z?
> Thanks,
> Regina
> ________________________________
> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
> Sent: Tue 10/7/2008 12:59 PM
> To: PostGIS Development Discussion; PostGIS Users Discussion
> Subject: Re: [postgis-devel] Dropped DM (Time) dimension with intersections
>
> Unfortunately, there's no such thing as a 3D polygon, except for
> trivial cases (the triangle, the shape with all Z's the same).
> Everything else is unclear on how to interpret the enclosed "plane"
> (if that is what it is) formed by an irregularly elevated boundary. So
> we can store the things, but there's really no decent way to interpret
> them in generality. For that we need the real stuff, Surfaces,
> volumes, etc.
>
> I think the "low hanging fruit" is probably more the "infrastructural
> requirement". We need a 4D index. That will allow us to handle things
> like 4D time tracks and point clouds efficiently, and form the
> indexing basis for future volumetric objects.
>
> P.
>
> On Tue, Oct 7, 2008 at 9:44 AM, Obe, Regina <robe.dnd at cityofboston.gov>
> wrote:
>> I'm not sure how low hanging the fruit :), but first off would be being
>> able
>> to do intersections and indexable ST_DWithin with 3D polygons and
>> linestrings and so forth. For example when I place a cable up on a roof I
>> need to know if I'm hitting another piece of equipment.
>>
>> Higher fruit - being able to support volumetric geometries.  Right now we
>> support 2d-3D polygons and lines and you can form wireframes with those,
>> but
>> no true volumetric stuff.  But then what do I know, I'm just parroting
>> things I've heard in whispers and those whispers are getting louder is all
>> :)
>>
>> There is still the issue of being able to display 3-D geometries without
>> spending a fortune on proprietary stuff which is not a PostGIS issue, but
>> has to gain in momentum to make PostGIS 3D more powerful (e.g. uDig for 3D
>> or OpenJump for 3D or OpenLayers for 3D?)
>>
>> Thanks,
>> Regina
>> ________________________________
>> From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul
>> Ramsey
>> Sent: Tue 10/7/2008 12:30 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Dropped DM (Time) dimension with
>> intersections
>>
>> Perhaps elabourate on what better 3D support would be? There's the
>> surface object hanging around. There's the issue of maintaining higher
>> dimensional coordinates through lower dimensional transforms (which
>> you saw the result of a few days ago). There's elabourating the
>> complete set of 3D objects and relationships (gulp).
>>
>> It's not clear to me what is the "low hanging fruit" that will make 3D
>> users happiest in the shortest time.
>>
>> P.
>>
>> On Tue, Oct 7, 2008 at 8:54 AM, Obe, Regina <robe.dnd at cityofboston.gov>
>> wrote:
>>> Margie,
>>>
>>> Unfortunately I think the answer is no.  Most of the work going on in 1.4
>>> is
>>> to improve speed of existing functionality and reorganize the source to
>>> make
>>> it more maintainable.
>>>
>>> Someone please correct me if I am wrong.
>>>
>>> I for one would be very elated if we had better 3D support since CityGML
>>> and
>>> similar initiatives are becoming more of a hot topic around here.
>>>
>>> Thanks,
>>> Regina
>>> ________________________________
>>> From: postgis-devel-bounces at postgis.refractions.net
>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>> Huntington, Margaret (US SSA)
>>> Sent: Tuesday, October 07, 2008 11:47 AM
>>> To: postgis-devel at postgis.refractions.net
>>> Subject: [postgis-devel] Dropped DM (Time) dimension with intersections
>>>
>>> Hello,
>>>
>>>     Currently I'm using PostGIS 1.3.3.  From past discussions and from
>>> testing, both the st_intersection st_extend methods return 2D results
>>> with
>>> 4D input geometries.  As a temporary work-around, I had hoped
>>> st_intersection might work with 3DM geometries.  (Plan was to interpolate
>>> the altitude value within the function call if PostGIS could calculate
>>> the
>>> time dimension).   I found time components are also dropped by
>>> st_intersection with 3DM geometries.  I abandoned usage of 4D bounding
>>> boxes
>>> since these too effectively degrade 4D geometries down to 2D geometries
>>> (altitude and time are zeroed out).
>>>
>>>     polyGeometry geometry;
>>>
>>>     bbGeometry geometry;
>>>
>>>     intersectionGeometry geometry;
>>>
>>>     coorddims smallint;
>>>
>>>            -- both polygon and linestring have an expected zmflag value
>>> of
>>> 1
>>>
>>>            polyGeometry := 'SRID=4326;POLYGONM((0 0 0, 0 10 4, 10 10 4,
>>> 10
>>> 0
>>> 0, 0 0 0))'::geometry;
>>>
>>>            bbGeometry := 'SRID=4326;LINESTRINGM(0 0 1.5, 10 10
>>> 2)'::geometry;
>>>
>>>            intersectionGeometry := st_intersection(polyGeometry,
>>> bbGeometry);
>>>
>>>            -- st_intersection method drops the time dimension; zmflag
>>> value
>>> of 0
>>>
>>>            coorddims := st_zmflag(intersectionGeometry);
>>>
>>> If I were to download the subversion snapshot, the current 1.4 version,
>>> might st_intersection work with either 3DM or 4D geometries?  Are
>>> bounding
>>> boxed or st_extend improved for either 3DM or 4D geometries?  I had
>>> incorporated polygons only as a possible work-around to the bounding box
>>> and
>>> st_extend 2D limitations.
>>>
>>> Margie
>>>
>>> ________________________________
>>>
>>> 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.
>>>
>>> ________________________________
>>>
>>> Help make the earth a greener place. If at all possible resist printing
>>> this
>>> email and join us in saving paper.
>>>
>>> _______________________________________________
>>> 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
>>
>> ________________________________
>>
>> 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.
>>
>> ________________________________
>>
>> Help make the earth a greener place. If at all possible resist printing
>> this
>> email and join us in saving paper.
>>
>> _______________________________________________
>> 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
>
> ________________________________
>
> 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.
>
> ________________________________
>
> Help make the earth a greener place. If at all possible resist printing this
> email and join us in saving paper.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>