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
