[Mobilitydb-dev] MobilityDB and the MEOS library

Sat Jun 11 08:42:52 PDT 2022

Dear Krishna

Many thanks for your insights!

I fully understand that you have limited resources due to the strategic
shift of your employer. I will let you know how we advance in this project
so that you can share with us your valuable knowledge.

Regards

Esteban

On Fri, Jun 10, 2022 at 9:42 PM Krishna Chaitanya <bkchaitan94 at gmail.com>
wrote:

> Dear Professor,
>
> It is really amazing to see the progress. MobilityDB-OpenLayers
> <https://github.com/MobilityDB/MobilityDB-OpenLayers> looks great and
> seems very useful for visualizing such data. :)
>
> Regarding the development of a common library, I think it is definitely
> the way to go. As we discussed earlier, having such an engine decoupled
> from the database would unlock a lot of value to the community as a lot of
> more related tools can be built on top. And of course such an engine can
> only have its maximum potential if it stays interoperable with the actual
> database MobilityDB itself. So it is indeed the right step to keep the
> codebase common. Otherwise it's just additional maintenance work to keep
> both in sync.
>
> Regarding C vs C++, the reason I went with C++ for MEOS instead of C are
> the following:
>
>    1. My use case was to work with this data in Python, and provide a
>    good developer experience (DX) by being object-oriented, similar to
>    Shapely. Interfacing Python with C++ also seemed easier than with C, as
>    PyBind11 made it easy and more maintainable.
>    2. MEOS was mostly inspired by GEOS, and it was built in C++
>    3. Additionally, I, myself, am more accustomed to higher level
>    programming languages like Python and C++ than directly with C
>
> Also, it is worth mentioning that I did work briefly on exposing a C api
> to MEOS (it is in the capi <https://github.com/adonmo/meos/tree/capi>
> branch), and whatever has been built until then is functional.
>
> But at the same time, I understand why you want to build such engine in C,
> and it might actually be a better idea:
>
>    1. Since existing MobilityDB codebase is almost entire in C, it's only
>    natural and ideal for this engine to come organically from that way
>    2. With C, it would be possible to be more performant than C++
>    3. The only major problem I see with a C-lang first engine approach is
>    that providing Python bindings might prove to be a bit of higher effort,
>    and might need to be redone as most of pyMEOS code might not be reusable.
>    Also if our aim is to provide an object oriented interface for languages
>    like Python, some amount of bridging code from C's procedural code has to
>    be actively and carefully maintained. But in the long run, such approach
>    might be worth the performance benefits.
>
> Personally, from my side, although I'd love to see all of this happen,
> unfortunately a lot of things have changed in our company post-COVID. So I
> might find it hard to spend any time towards these efforts. We (Adonmo
> <https://www.adonmo.com/>) have actually pivoted our business completely
> out of taxi top screen advertising (which are moving screens), to
> residential lift lobby screen advertising (which are completely stationary
> screens), hence, technically we no longer have any active relevant use
> cases with the spatiotemporal data analysis area directly so to speak. Our
> screen network has been growing at breakneck speed last few months so I am
> now mostly busy on scaling challenges - ensuring more and more data to
> smoothly come into our system and be processed reliably, and in leading our
> growing engineering and product teams.
>
> I hope I helped in sharing my viewpoints. Please do let me know which is
> the approach you are planning/wanting to take, and if I could be of help in
> sharing any more thoughts or if you need my efforts in any other limited
> fashion towards this direction.
>
> Aside from all this, I also wanted to ask if you have considered of
> providing paid database cloud hosting option for MobilityDB similar to how
> TimescaleDB does <https://www.timescale.com/pricing>. I think that way it
> would be possible to further the project development more by being able to
> get more resources.
>
> Thanks,
> Krishna Chaitanya
>
> On Fri, 10 Jun 2022 at 14:37, Esteban Zimanyi <estebanzimanyi at gmail.com>
> wrote:
>
>> Dear Krishna
>>
>> I hope you are doing well.
>>
>> I wanted to inform you about our current ongoing work on MobilityDB
>> towards creating a C library MEOS.
>>
>> Our users are continuously asking for streaming support for MobilityDB.
>> In this context users work independently of a database on main memory
>> collecting GPS observations from, e.g., a Kafka stream, cleaning this
>> data, visualizing it using, e.g., Open Layers
>> https://github.com/MobilityDB/MobilityDB-OpenLayers
>> and when more recent data is available, save the previous data into
>> MobilityDB and continue working with the latest observations.
>>
>> I know very well that this is the use case for which you created the MEOS
>> and pyMEOS projects
>> https://github.com/adonmo/meos
>> https://pypi.org/project/pymeos/
>> Alas, we do not have the resources to continue in parallel the
>> development of MobilityDB in C and MEOS in C++
>>
>> For this reason I have been working the last 6 months (even before the
>> official MobilityDB 1.0 release in April 2022) for enabling the SAME code
>> base to be used for building both MobilityDB and MEOS. That was a
>> challenging task from an architectural perspective but soon we will have a
>> first version of the MEOS library to begin testing it. However, please be
>> aware that this is still work in progress!
>>
>> You will find in the following link
>>  libMEOS.zip
>> <https://drive.google.com/file/d/1vkeMa3PFvX4zcLwDnNe1c-kJqSnZyqbm/view?usp=drive_web>
>> the doxygen documentation of the library. Please unzip the file and open
>> the file modules.html which is the main file for the documentation
>>
>> [image: image.png]
>> [image: image.png]
>> [image: image.png]
>> [image: image.png]
>>
>> As you can see from the screen shots above, the links of each MEOS
>> function and the corresponding SQL function or operator is explicitly
>> mentioned. This documentation can be obtained from the develop version of
>> MobilityDB with the commands (issued in the build directory)
>>
>> ~/src/MobilityDB/build$ rm -rf *
>> ~/src/MobilityDB/build$ cmake -DMEOS=on -DDOC_DEV=on ..
>> ~/src/MobilityDB/build$ make -j
>> ~/src/MobilityDB/build$ make doc_dev
>>
>> I wanted to discuss with you how we can join our efforts in this respect
>> to make the MEOS library a reality, in particular, how your previous work
>> on MEOS and pyMEOS could be integrated with the current MobilityDB/MEOS
>> code base. Please let me know your viewpoint on this.
>>
>> FYI we have bought the domains libmeos.org and libmeos.com to follow a
>> similar path as https://libgeos.org/
>>
>> Regards
>>
>> Esteban
>>
>> ------------------------------------------------------------
>> Prof. Esteban Zimanyi
>> Department of Computer & Decision Engineering  (CoDE) CP 165/15
>> Universite Libre de Bruxelles
>> Avenue F. D. Roosevelt 50
>> B-1050 Brussels, Belgium
>> fax: + 32.2.650.47.13
>> tel: + 32.2.650.31.85
>> e-mail: esteban.zimanyi at ulb.be
>> Internet: http://cs.ulb.ac.be/members/esteban/
>> ------------------------------------------------------------
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mobilitydb-dev/attachments/20220611/161cd805/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 260382 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mobilitydb-dev/attachments/20220611/161cd805/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 299732 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mobilitydb-dev/attachments/20220611/161cd805/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 180574 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mobilitydb-dev/attachments/20220611/161cd805/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177260 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mobilitydb-dev/attachments/20220611/161cd805/attachment-0007.png>