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 <[EMAIL PROTECTED]> >>> 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: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> >>>> 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: [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] On Behalf Of >>>>> Huntington, Margaret (US SSA) >>>>> Sent: Tuesday, October 07, 2008 11:47 AM >>>>> To: [EMAIL PROTECTED] >>>>> 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 >>>>> [EMAIL PROTECTED] >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> postgis-devel mailing list >>>> [EMAIL PROTECTED] >>>> 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 >>>> [EMAIL PROTECTED] >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel >>>> >>>> >>>> >>> _______________________________________________ >>> postgis-users mailing list >>> [email protected] >>> http://postgis.refractions.net/mailman/listinfo/postgis-users >>> >>> >>> >> >> > > > -- > Regards, > > Chris Hermansen mailto:[EMAIL PROTECTED] > 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 > [email protected] > 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. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
