<div dir="ltr"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Alas, enabling real 3D intersection requires calling the PostGIS function ST_3DIntersects which in turn requires the SFCGAL backend.</div><div><br></div><div>This has not yet been tested with MobilityDB but indeed it is a nice extension that will be envisioned in the future. </div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 20, 2021 at 7:24 PM Sharath S Bhargav <<a href="mailto:shrthsbhargav96@gmail.com" target="_blank">shrthsbhargav96@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Esteban,<div><br></div><div>Apologies for late reply. </div><div>Would this work if the polygon also defined in 3 dimensions? As in if it was a pure 3 dimensional operation. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 16, 2021 at 4:52 PM Esteban Zimanyi <<a href="mailto:estebanzimanyi@gmail.com" target="_blank">estebanzimanyi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Sharath<div><br></div><div>I created a small example to see whether it fits your requirements. In my local working copy of MobilityDB I enabled the operations on mixed 2D and 3D geometries (currently disallowed in MobilityDB). The example looks as follows.</div><div><br></div><div>select astext(atGeometry(tgeompoint '[Point(0 0 0)@2000-01-01, Point(4 4 4)@2000-01-05]', geometry 'Polygon((1 1,1 2,2 2,2 1,1 1))'));<br>                                       astext<br>------------------------------------------------------------------------------------<br> {[POINT Z (1 1 1)@2000-01-02 00:00:00+01, POINT Z (2 2 2)@2000-01-03 00:00:00+01]}<br>(1 row)<br></div><div><br></div><div>Does this correspond to your requirements ?</div><div><br></div><div>Esteban</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 13, 2021 at 4:56 AM Sharath S Bhargav <<a href="mailto:shrthsbhargav96@gmail.com" target="_blank">shrthsbhargav96@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Esteban,<div><br><div>The method st_3DIntersection is required for true 3D intersection. While st_intersection does return results with points having 3 dimensions by averaging the Z dimension value. But the results returned from MobilityDB seem to indicate that is also not supported since I get a tbool with only false values. Can I assume that MobilityDB does not support 3 dimensions in any of the intersection functions even in a 2.5D fashion?</div></div><div>If the tintersect function could return true by just considering the 2 dimensions of the trajectory and average out the Z dimension that would also work for me. I expected this behaviour since MobilityDB delegates the spatial calculations to PostGIS and PostGIS does actually do the same and return the intersecting line string as shown in the query example. So considering PostGIS response, I was hoping MobilityDB could return a true period set. It would be great if you could kindly clarify the behaviour in this scenario. Apologies if I seem to be asking trivial questions, I am new to the Spatio-Temporal Databases.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 13, 2021 at 3:14 AM Esteban Zimanyi <<a href="mailto:estebanzimanyi@gmail.com" target="_blank">estebanzimanyi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Dear Sharath<br clear="all"><div><div dir="ltr"><div dir="ltr"><div><br></div><div>As I mentioned before, MobilityDB delegates to PostGIS the calculation of the spatial operations. According to what you described, to implement your scenario you require to use the PostGIS method ST_3DIntersection</div><div><a href="https://postgis.net/docs/ST_3DIntersection.html" target="_blank">https://postgis.net/docs/ST_3DIntersection.html</a><br></div><div>It is stated in the above link that this method needs SFCGAL backend. </div><div><br></div><div>We have never used MobilityDB together with SFCGAL. We could envision starting this exploration in the future, but currently we have many other things in the development pipeline of MobilityDB. </div><div><br></div><div>If you want to start this exploration, we could provide you guidance in this regard and depending on our availability, we can also extend MobilityDB to make this happen.</div><font color="#888888"><div><br>Esteban</div><div><br></div></font></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Regards,<div>Sharath</div><div><br></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Regards,<div>Sharath</div><div><br></div></div></div>
</blockquote></div>