[Mobilitydb-users] Query regarding intersection of a temporal point with Z dimension and polygon

[Esteban Zimanyi]

Alas, enabling real 3D intersection requires calling the PostGIS function
ST_3DIntersects which in turn requires the SFCGAL backend.

This has not yet been tested with MobilityDB but indeed it is a nice
extension that will be envisioned in the future.

On Sat, Mar 20, 2021 at 7:24 PM Sharath S Bhargav <shrthsbhargav96 at gmail.com>
wrote:

> Hello Esteban,
>
> Apologies for late reply.
> Would this work if the polygon also defined in 3 dimensions? As in if it
> was a pure 3 dimensional operation.
>
> On Tue, Mar 16, 2021 at 4:52 PM Esteban Zimanyi <estebanzimanyi at gmail.com>
> wrote:
>
>> Dear Sharath
>>
>> 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.
>>
>> 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))'));
>>                                        astext
>>
>> ------------------------------------------------------------------------------------
>>  {[POINT Z (1 1 1)@2000-01-02 00:00:00+01, POINT Z (2 2 2)@2000-01-03
>> 00:00:00+01]}
>> (1 row)
>>
>> Does this correspond to your requirements ?
>>
>> Esteban
>>
>>
>> On Sat, Mar 13, 2021 at 4:56 AM Sharath S Bhargav <
>> shrthsbhargav96 at gmail.com> wrote:
>>
>>> Hello Esteban,
>>>
>>> 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?
>>> 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.
>>>
>>> On Sat, Mar 13, 2021 at 3:14 AM Esteban Zimanyi <
>>> estebanzimanyi at gmail.com> wrote:
>>>
>>>> Dear Sharath
>>>>
>>>> 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
>>>> https://postgis.net/docs/ST_3DIntersection.html
>>>> It is stated in the above link that this method needs SFCGAL backend.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Esteban
>>>>
>>>>
>>>
>>> --
>>> Regards,
>>> Sharath
>>>
>>>
>
> --
> Regards,
> Sharath
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mobilitydb-users/attachments/20210321/771cd84f/attachment.html>