[postgis-users] [postgis-devel] Dropped DM (Time) dimension with intersections
Margie Huntington
margaret.huntington at baesystems.com
Mon Oct 13 14:48:17 PDT 2008
Thanks for the idea Chris; but, I've already incorporated those ideas. First
the list of possible conflicting routes is obtained with st_dwithin. Then
buffered checks for overlapping time and altitude are preformed on the
individual line segments prior to evaluating st_dwithin on the segments
themselves.
I'll use another function after using postgis to locate the list of possible
conflicting segments. But I hope st_intersection, st_extend and bounding
boxes might someday incorporate 4D functionality.
Chris Hermansen wrote:
>
> Your problem sounds to me like "find the distance from each one of these
> points to all the other points", and that is a problem that requires a
> great deal of computation.
>
> The 4D indexes that Paul says we need would definitely come at least
> partway to your rescue here. But failing that, you need to come up with
> a low-cost way to minimize the amount of "potential close points" that
> you need to examine against a specific test point.
>
> Only select potential close points within some (M-e,M+e) time. Only
> select potential close points within some (Z-b,Z+b) elevation range.
> Only select potential close points within some st_expand() of size b
> around the test point. This would let you use your existing B+tree and
> GiST indexes to quickly narrow down the points to be tested. Then you
> can compute your distances on any remaining points.
>
> Presumably if you also record that you've compared test track T against
> another track U, when you get around to testing U you needn't compare it
> against T.
>
> This is still a great deal of computation.
>
> Margie Huntington wrote:
>> 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 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-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>>
>>>
>>
>>
>
>
> --
> Regards,
>
> Chris Hermansen mailto:chris.hermansen at timberline.ca
> tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644
> Timberline Natural Resource Group · http://www.timberline.ca
> 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
--
View this message in context: http://www.nabble.com/Re%3A--postgis-devel--Dropped-DM-%28Time%29-dimension-with-intersections-tp19862743p19963583.html
Sent from the PostGIS - User mailing list archive at Nabble.com.
More information about the postgis-users
mailing list