[postgis-users] [postgis-devel] Dropped DM (Time) dimension with intersections
Margie Huntington
margaret.huntington at baesystems.com
Mon Oct 13 11:08:17 PDT 2008
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
>
>
--
View this message in context: http://www.nabble.com/Re%3A--postgis-devel--Dropped-DM-%28Time%29-dimension-with-intersections-tp19862743p19959830.html
Sent from the PostGIS - User mailing list archive at Nabble.com.
More information about the postgis-users
mailing list