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

Sharath S Bhargav shrthsbhargav96 at gmail.com
Tue Mar 23 08:17:00 PDT 2021


Hey Esteban,

Thank you for taking your time to give me detailed answers. I think I will
try and model my 3rd dimension as a separate entity and query accordingly
since MobilityDB does not allow me to query in 3 dimensions.
Will get back if I have any clarifications.

On Mon, Mar 22, 2021 at 3:36 PM Esteban Zimanyi <estebanzimanyi at gmail.com>
wrote:

> As a follow up of my previous answer, as you know MobilityDB delegates
> spatial processing to PostGIS.
>
> I sketched in the examples below an original MobilityDB query, the
> corresponding query sent to PostGIS, and the answer received from PostGIS.
> As you can see, real 3D operations without SFCGAL are not possible.
>
> -- Intersection with vertical plane at x = 2
> SELECT asText(atGeometry(tgeompoint '[Point(0 0 0)@2000-01-01, Point(3 3
> 3)@2000-01-04]',
>   geometry 'Polygon Z((2 0 0,2 3 0,2 3 3, 2 0 3,2 0 0))'));
>
> => Corresponding PostGIS query
>
> SELECT ST_asText(ST_Intersection(geometry 'Linestring Z(0 0 0,3 3 3)',
>   geometry 'Polygon Z((2 0 0,2 3 0,2 3 3, 2 0 3,2 0 0))'));
> -- LINESTRING EMPTY
>
> -- Intersection with horizontal plane at z = 2
> SELECT asText(atGeometry(tgeompoint '[Point(0 0 0)@2000-01-01, Point(3 3
> 3)@2000-01-04]',
>   geometry 'Polygon Z((0 0 2,3 0 2,3 3 2,0 3 2,0 0 2))'));
>
> => Corresponding PostGIS query
>
> SELECT ST_asText(ST_Intersection(geometry 'Linestring Z(0 0 0,3 3 3)',
>   geometry 'Polygon Z((0 0 2,3 0 2,3 3 2,0 3 2,0 0 2))'));
>  LINESTRING Z (0 0 0,3 3 3)
>
>
> On Sun, Mar 21, 2021 at 7:50 PM Esteban Zimanyi <estebanzimanyi at gmail.com>
> wrote:
>
>> 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
>>>
>>>

-- 
Regards,
Sharath
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mobilitydb-users/attachments/20210323/7e305c63/attachment.html>


More information about the Mobilitydb-users mailing list