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

> I think there is a miscommunication.  I'm attempting to model moving objects
> in the database; specifically aircraft.  These aircraft have both an
> altitude and time as well as the normal x- and y- components.  The problem
> is, I haven't found a function that will return time, the m-component. (I
> can determine altitude myself since the points are linear; thus, this
> omission isn't as critical.)
>
> I'd like to determine if aircraft maintain a safe distance from each other.
> I had hoped st_expand would model a moving bounding box; but it only returns
> an x-, y-geometry.   The st_zmflag is 0:
>
>
> >From my perspective, a
>
>     shorterSegment geometry;
>     shorterSegmentBuffer geometry;
>     coorddims smallint;  
>
>            shorterSegment:= 'SRID=4326;LINESTRINGM(0 0 1.5, 10 10
> 2)'::geometry;      
>
>         shorterSegmentBuffer := st_expand(shorterSegment, exactdistance);
>         coorddims := st_zmflag(shorterSegmentBuffer);    
>
> Same problem exists for st_intersection; only 2D geometries are returned
> since the z-component is zeroed out.  The st_intersection function indicates
> an intersection over the entire flight path even when the aircraft are
> separated by days.  The M-component is critical since aircraft fly in the
> same flight path; same x-, y- and z-components.
>
> There aren't plans to make the M-component operational for st_expand() nor
> for st_intersection()?  I was attempting a polygon surface only because
> there isn't a 3D nor 4D bounding box that works with time.
>
>
> Paul Ramsey-3 wrote:
>  
>> 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@...>
>> 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@... 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@...>
>>> 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@...
>>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>>> Huntington, Margaret (US SSA)
>>>> Sent: Tuesday, October 07, 2008 11:47 AM
>>>> To: postgis-devel@...
>>>> 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@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>        
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> 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@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>>      
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>>    
>
>