<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [postgis-users] [postgis-devel] Dropped DM (Time) dimensionwith
intersections</title>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="State"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="country-region"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hello <st1:City w:st="on"><st1:place
w:st="on">Regina</st1:place></st1:City>,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I’m only performing st_expand and
st_intersection on segments whose time interval overlap another route’s
segment. OK, you’re correct. I won’t find intersections
on routes where they’re two days apart. An exaggeration. But
if an aircraft stays within a route with the same bearing for 30 minutes and
there are 5 subsequent aircraft spaced at 5-minute intervals, all five will be
returned with the st_intersection function. We’re discussing the
easy case. What about an aircraft that comes close or has intersecting
paths that aren’t utilizing the same route? If they intersect
at the same x-,y-, z- component a minute or so apart, there isn’t an
intersection; thus the reason I’d like a moving bounding box.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for considering the issue,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Margie<o:p></o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
postgis-users-bounces@postgis.refractions.net
[mailto:postgis-users-bounces@postgis.refractions.net] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Obe, Regina<br>
<b><span style='font-weight:bold'>Sent:</span></b> Monday, October 13, 2008
1:14 PM<br>
<b><span style='font-weight:bold'>To:</span></b> PostGIS Users Discussion;
postgis-users@postgis.refractions.net<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [postgis-users]
[postgis-devel] Dropped DM (Time) dimensionwithintersections</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p style='margin-bottom:12.0pt'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>Margie,<br>
<br>
This may be a dumb question on my part, but why can't you keep track of time
separate from space with a datetime field and then use the numerous functions
in postgresql for doing datetime overlap comparisons combined with spatial
overlaps.<br>
<br>
Thanks,<br>
<st1:City w:st="on"><st1:place w:st="on">Regina</st1:place></st1:City><br>
<br>
<br>
-----Original Message-----<br>
From: postgis-users-bounces@postgis.refractions.net on behalf of Margie
Huntington<br>
Sent: Mon 10/13/2008 2:08 PM<br>
To: postgis-users@postgis.refractions.net<br>
Subject: Re: [postgis-users] [postgis-devel] Dropped DM (Time) dimensionwith
intersections<br>
<br>
<br>
I think there is a miscommunication. I'm attempting to model moving
objects<br>
in the database; specifically aircraft. These aircraft have both an<br>
altitude and time as well as the normal x- and y- components. The problem<br>
is, I haven't found a function that will return time, the m-component. (I<br>
can determine altitude myself since the points are linear; thus, this<br>
omission isn't as critical.)<br>
<br>
I'd like to determine if aircraft maintain a safe distance from each other.<br>
I had hoped st_expand would model a moving bounding box; but it only returns<br>
an x-, y-geometry. The st_zmflag is 0:<br>
<br>
<br>
>From my perspective, a<br>
<br>
shorterSegment geometry;<br>
shorterSegmentBuffer geometry;<br>
coorddims smallint; <br>
<br>
shorterSegment:=
'SRID=4326;LINESTRINGM(0 0 1.5, 10 10<br>
2)'::geometry; <br>
<br>
shorterSegmentBuffer :=
st_expand(shorterSegment, exactdistance);<br>
coorddims :=
st_zmflag(shorterSegmentBuffer); <br>
<br>
Same problem exists for st_intersection; only 2D geometries are returned<br>
since the z-component is zeroed out. The st_intersection function
indicates<br>
an intersection over the entire flight path even when the aircraft are<br>
separated by days. The M-component is critical since aircraft fly in the<br>
same flight path; same x-, y- and z-components.<br>
<br>
There aren't plans to make the M-component operational for st_expand() nor<br>
for st_intersection()? I was attempting a polygon surface only because<br>
there isn't a 3D nor 4D bounding box that works with time.<br>
<br>
<br>
Paul Ramsey-3 wrote:<br>
><br>
> Unfortunately, there's no such thing as a 3D polygon, except for<br>
> trivial cases (the triangle, the shape with all Z's the same).<br>
> Everything else is unclear on how to interpret the enclosed
"plane"<br>
> (if that is what it is) formed by an irregularly elevated boundary. So<br>
> we can store the things, but there's really no decent way to interpret<br>
> them in generality. For that we need the real stuff, Surfaces,<br>
> volumes, etc.<br>
><br>
> I think the "low hanging fruit" is probably more the
"infrastructural<br>
> requirement". We need a 4D index. That will allow us to handle things<br>
> like 4D time tracks and point clouds efficiently, and form the<br>
> indexing basis for future volumetric objects.<br>
><br>
> P.<br>
><br>
> On Tue, Oct 7, 2008 at 9:44 AM, Obe, <st1:City w:st="on"><st1:place w:st="on">Regina</st1:place></st1:City>
<robe.dnd@cityofboston.gov><br>
> wrote:<br>
>> I'm not sure how low hanging the fruit :), but first off would be
being<br>
>> able<br>
>> to do intersections and indexable ST_DWithin with 3D polygons and<br>
>> linestrings and so forth. For example when I place a cable up on a
roof I<br>
>> need to know if I'm hitting another piece of equipment.<br>
>><br>
>> Higher fruit - being able to support volumetric geometries.
Right now we<br>
>> support 2d-3D polygons and lines and you can form wireframes with
those,<br>
>> but<br>
>> no true volumetric stuff. But then what do I know, I'm just parroting<br>
>> things I've heard in whispers and those whispers are getting louder is<br>
>> all<br>
>> :)<br>
>><br>
>> There is still the issue of being able to display 3-D geometries
without<br>
>> spending a fortune on proprietary stuff which is not a PostGIS issue,
but<br>
>> has to gain in momentum to make PostGIS 3D more powerful (e.g. uDig
for<br>
>> 3D<br>
>> or OpenJump for 3D or OpenLayers for 3D?)<br>
>><br>
>> Thanks,<br>
>> <st1:City w:st="on"><st1:place w:st="on">Regina</st1:place></st1:City><br>
>> ________________________________<br>
>> From: postgis-devel-bounces@postgis.refractions.net on behalf of Paul<br>
>> Ramsey<br>
>> Sent: Tue 10/7/2008 12:30 PM<br>
>> To: PostGIS Development Discussion<br>
>> Subject: Re: [postgis-devel] Dropped DM (Time) dimension with<br>
>> intersections<br>
>><br>
>> Perhaps elabourate on what better 3D support would be? There's the<br>
>> surface object hanging around. There's the issue of maintaining higher<br>
>> dimensional coordinates through lower dimensional transforms (which<br>
>> you saw the result of a few days ago). There's elabourating the<br>
>> complete set of 3D objects and relationships (gulp).<br>
>><br>
>> It's not clear to me what is the "low hanging fruit" that
will make 3D<br>
>> users happiest in the shortest time.<br>
>><br>
>> P.<br>
>><br>
>> On Tue, Oct 7, 2008 at 8:54 AM, Obe, <st1:City w:st="on"><st1:place
w:st="on">Regina</st1:place></st1:City> <robe.dnd@cityofboston.gov><br>
>> wrote:<br>
>>> Margie,<br>
>>><br>
>>> Unfortunately I think the answer is no. Most of the work
going on in<br>
>>> 1.4<br>
>>> is<br>
>>> to improve speed of existing functionality and reorganize the
source to<br>
>>> make<br>
>>> it more maintainable.<br>
>>><br>
>>> Someone please correct me if I am wrong.<br>
>>><br>
>>> I for one would be very elated if we had better 3D support since
CityGML<br>
>>> and<br>
>>> similar initiatives are becoming more of a hot topic around here.<br>
>>><br>
>>> Thanks,<br>
>>> <st1:City w:st="on"><st1:place w:st="on">Regina</st1:place></st1:City><br>
>>> ________________________________<br>
>>> From: postgis-devel-bounces@postgis.refractions.net<br>
>>> [<a href="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</a>]
On Behalf Of<br>
>>> Huntington, Margaret (<st1:country-region w:st="on"><st1:place
w:st="on">US</st1:place></st1:country-region> SSA)<br>
>>> Sent: Tuesday, October 07, 2008 11:47 AM<br>
>>> To: postgis-devel@postgis.refractions.net<br>
>>> Subject: [postgis-devel] Dropped DM (Time) dimension with
intersections<br>
>>><br>
>>> Hello,<br>
>>><br>
>>> Currently I'm using PostGIS 1.3.3.
>From past discussions and from<br>
>>> testing, both the st_intersection st_extend methods return 2D
results<br>
>>> with<br>
>>> 4D input geometries. As a temporary work-around, I had hoped<br>
>>> st_intersection might work with 3DM geometries. (Plan was to<br>
>>> interpolate<br>
>>> the altitude value within the function call if PostGIS could
calculate<br>
>>> the<br>
>>> time dimension). I found time components are also
dropped by<br>
>>> st_intersection with 3DM geometries. I abandoned usage of 4D
bounding<br>
>>> boxes<br>
>>> since these too effectively degrade 4D geometries down to 2D
geometries<br>
>>> (altitude and time are zeroed out).<br>
>>><br>
>>> polyGeometry geometry;<br>
>>><br>
>>> bbGeometry geometry;<br>
>>><br>
>>> intersectionGeometry geometry;<br>
>>><br>
>>> coorddims smallint;<br>
>>><br>
>>>
-- both polygon and linestring have an expected zmflag value<br>
>>> of<br>
>>> 1<br>
>>><br>
>>>
polyGeometry := 'SRID=4326;POLYGONM((0 0 0, 0 10 4, 10 10 4,<br>
>>> 10<br>
>>> 0<br>
>>> 0, 0 0 0))'::geometry;<br>
>>><br>
>>>
bbGeometry := 'SRID=4326;LINESTRINGM(0 0 1.5, 10 10<br>
>>> 2)'::geometry;<br>
>>><br>
>>>
intersectionGeometry := st_intersection(polyGeometry,<br>
>>> bbGeometry);<br>
>>><br>
>>>
-- st_intersection method drops the time dimension; zmflag<br>
>>> value<br>
>>> of 0<br>
>>><br>
>>>
coorddims := st_zmflag(intersectionGeometry);<br>
>>><br>
>>> If I were to download the subversion snapshot, the current 1.4
version,<br>
>>> might st_intersection work with either 3DM or 4D geometries?
Are<br>
>>> bounding<br>
>>> boxed or st_extend improved for either 3DM or 4D geometries?
I had<br>
>>> incorporated polygons only as a possible work-around to the
bounding box<br>
>>> and<br>
>>> st_extend 2D limitations.<br>
>>><br>
>>> Margie<br>
>>><br>
>>> ________________________________<br>
>>><br>
>>> The substance of this message, including any attachments, may be<br>
>>> confidential, legally privileged and/or exempt from disclosure
pursuant<br>
>>> to<br>
>>> <st1:State w:st="on"><st1:place w:st="on">Massachusetts</st1:place></st1:State>
law. It is intended solely for the addressee. If you<br>
>>> received<br>
>>> this in error, please contact the sender and delete the material
from<br>
>>> any<br>
>>> computer.<br>
>>><br>
>>> ________________________________<br>
>>><br>
>>> Help make the earth a greener place. If at all possible resist
printing<br>
>>> this<br>
>>> email and join us in saving paper.<br>
>>><br>
>>> _______________________________________________<br>
>>> postgis-devel mailing list<br>
>>> postgis-devel@postgis.refractions.net<br>
>>> <a
href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> postgis-devel mailing list<br>
>> postgis-devel@postgis.refractions.net<br>
>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
>><br>
>> ________________________________<br>
>><br>
>> The substance of this message, including any attachments, may be<br>
>> confidential, legally privileged and/or exempt from disclosure
pursuant<br>
>> to<br>
>> <st1:State w:st="on"><st1:place w:st="on">Massachusetts</st1:place></st1:State>
law. It is intended solely for the addressee. If you<br>
>> received<br>
>> this in error, please contact the sender and delete the material from
any<br>
>> computer.<br>
>><br>
>> ________________________________<br>
>><br>
>> Help make the earth a greener place. If at all possible resist
printing<br>
>> this<br>
>> email and join us in saving paper.<br>
>><br>
>> _______________________________________________<br>
>> postgis-devel mailing list<br>
>> postgis-devel@postgis.refractions.net<br>
>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
>><br>
>><br>
> _______________________________________________<br>
> postgis-users mailing list<br>
> postgis-users@postgis.refractions.net<br>
> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
><br>
><br>
<br>
--<br>
View this message in context: <a
href="http://www.nabble.com/Re%3A--postgis-devel--Dropped-DM-%28Time%29-dimension-with-intersections-tp19862743p19959830.html">http://www.nabble.com/Re%3A--postgis-devel--Dropped-DM-%28Time%29-dimension-with-intersections-tp19862743p19959830.html</a><br>
Sent from the PostGIS - User mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
postgis-users mailing list<br>
postgis-users@postgis.refractions.net<br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a></span></font><o:p></o:p></p>
</div>
</body>
</html>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY><P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>