Vision for MovingPandas 1.0

[anitagraser]

Envisioned key improvements:

• More efficient processing by integrating MEOS & PyMEOS
• Make plotting dependencies optional #78 or splitting processing and visualization (similar to the modular structure of PySAL) to enable easier integrate e.g. into a QGIS plugin
  
• Parallelization of computations on TrajectoryCollections, e.g. using Dask or Polars
• add type hinting to codebase #252

Looking forward to hearing your thoughts and ideas.

[anitagraser]

PyMEOS is still at an early stage. Some experiments have started: https://github.com/anitagraser/PyMEOS/blob/cf7458c44f11718e742ab9ce24c274f101b0b5f5/pymeos_examples/MovingPandas/mpd-to-pymeos.ipynb

[giorgostheo]

I guess the most important 1.0 changes are going to be focused on performance upgrades right? Ideas like pymeos polars etc are interesting for sure, my only worry is that the initial codebase will need to be changed significantly in order to support these new backends. Also, wrt to pymeos mainly, the API seems rather limited for now.

Thoughts?

[anitagraser]

Yes, PyMEOS is in a very early stage. Maybe too early to make a decision on yet. However, instead of reinventing the wheel by writing our own implementations of all the functionality already covered in MEOS, I tend towards pooling our efforts in a joint library with Python bindings. Maybe @estebanzimanyi can share his (Py)MEOS development plans.

Significant changes to the code base (and potentially API breaks) are what major version changes are for, right? ;-)

[anitagraser]

FYI, @estebanzimanyi is currently assessing the differences between MovingPandas functionality and the (Py)MEOS API. The working document is: https://docs.google.com/document/d/1YdQanG-t5F6C1nkvZ2MyOFf_hec9aRLgpHRC433FUk8/edit?usp=sharing

[estebanzimanyi]

Dear Anita (cc Victor) I fully share your vision of "pooling our efforts in a joint library with Python bindings". This joint work will immensely benefit the full mobility domain. Therefore I think we can design this joint work together in a conference call with all of us. From the MEOS/MobilityDB perspective there are no major modifications foreseen in the future, we are already testing and packaging the future MobilityDB version 1.1. The release of this version will be in parallel with PyMEOS 1.0. We can even foresee releasing them together with Moving Pandas 1.0. If this sounds feasible or interesting to you I am looking forward to collaborating with you to achieve this. 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: ***@***.*** Internet: http://cs.ulb.ac.be/members/esteban/ ------------------------------------------------------------

On Tue, Nov 22, 2022 at 9:15 PM Anita Graser ***@***.***> wrote: Yes, PyMEOS is in a very early stage. Maybe too early to make a decision on yet. However, instead of reinventing the wheel by writing our own implementations of all the functionality already covered in MEOS, I tend towards pooling our efforts in a joint library with Python bindings. Maybe @estebanzimanyi <https://github.com/estebanzimanyi> can share his (Py)MEOS development plans. Significant changes to the code base (and potentially API breaks) are what major version changes are for, right? ;-) — Reply to this email directly, view it on GitHub <#258 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNHMBXD2HW6IEQWJJAK6LLWJUSWXANCNFSM6AAAAAASEZFTBM> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[anitagraser]

Thank you for your swift response, Esteban. One key issue will be Windows support for (Py)MEOS. As mentioned to Victor, lack of Win support would be a showstopper for MovingPandas dependencies.

Related:

• Windows support? MobilityDB/PyMEOS#1
• Windows build MobilityDB/MobilityDB#176

[estebanzimanyi]

Dear Anita We have already started to look at Windows support. Many thanks for pointing this out. Are there any other missing dependencies that we should consider? Regards Esteban Message ID: <anitagraser/movingpandas/repo-discussions/258/comments/4210408@

…

github.com>

[anitagraser]

That's great to know that win support is in the works. Ideally, PyMEOS should be made available via conda-forge to make installation as straightforward as possible.

[raybellwaves]

My two cents from my PyData Miami talk.

My looking at the convo above: flexible backends for big data/speed ups would be interesting e.g. dask and/or polars. I don't likely have development time for this but my thinking was a dask-movingpandas repo as a proof of concept.

My other ideas come how things are done in xarray. xarray has a nice html repr for it's objects (pydata/xarray#1627). Trajectory collection can have the same methods as Trajectory

[anitagraser]

Great ideas! Re dashboards: there's also https://discourse.holoviz.org/t/try-out-panel-sharing/4549 | https://awesome-panel.org/sharing? by Marc Skov Madsen

[anitagraser]

I've created a feature request for the improved html repr

• Nice html repr for trajectories #293

[anitagraser]

Regarding better documentation, I've now created a page on movingpandas.org that lists the tutorials and analysis examples https://movingpandas.github.io/movingpandas/examples

[raybellwaves]

I don't think #252 needs to be done for a 1.0 release. Type hinting is an ongoing processes in many python libraries that were developed without any type hinting previously. People can chip away as this on an ad-hoc basis

[raybellwaves]

get method chaining to work e.g. traj.add_speed().to_point_gdf()

[anitagraser]

Would that mean that we should switch to add_speed() returning a modified copy of the trajectory by default (and only altering the original trajectory if inplace=True)?

[bamacgabhann]

It might be better to have inplace=False by default to keep current behaviour, and allow chaining with inplace=True. Or to define variations of method names e.g.

def plus_speed(self, overwrite=False, name=SPEED_COL_NAME, units=UNITS()):
    self.add_speed(overwrite, name, units)
    return self

[anitagraser]

Just ran into this issue again yesterday

Here's the ticket #382

[anitagraser]

I've implemented basic parallelism using multiprocessing #380