Getting ready for 0.16 release

[anitagraser]

This release will target users of Pandas 2.0 who need the fixes in 8ee9d7f

I still have to

• fix the failing (minimal environment) tests and then
• merge Added distance, speed, and acceleration unit handling (#234) #295
• complete Output unit handling #308

[anitagraser]

@raybellwaves have you had a chance to look at #295 to see if you're also happy with the solution?

[anitagraser]

the placement of the list of dictionaries of conversions, it could be moved out of trajectory.py

Right. Eventually, I think we should move that part out of trajectory.py and into a dedicated "units handling"/"conversion"/"???" utils script (similar to https://github.com/movingpandas/movingpandas/blob/main/movingpandas/geometry_utils.py)

[anitagraser]

I'm working on refactoring now

[raybellwaves]

@raybellwaves have you had a chance to look at #295 to see if you're also happy with the solution?

I haven't. Great to see mpd have unit handling. I often have to think about whether i'm working in m/s or knots.

My only comment (and again apologies @bamacgabhann for having little time to review the code) is to check parity with naming in https://pint.readthedocs.io/en/stable/. This project is used in other projects via https://github.com/hgrecco/pint-pandas and https://github.com/xarray-contrib/pint-xarray. Either way i'm happy we have a solution. Thanks @bamacgabhann

Now I think about this. I think pint comes from the physics community and the geo community rolled their own solution like in geopy.

[bamacgabhann]

Thanks. I am not sure if pint handles all the units mpd now can. I started by looking at geopy but quickly realised the limiting factor was the need to be able to handle whatever units the crs of a dataset might be in. Geopy doesn't handly them all. I couldn't actually find a list of CRS units anywhere, so I wrote a short script to transform a test dataset into every CRS in the proj database in turn, and extract each unique unit. That was the base unit list, and I just kept all the names which were extracted from that. I then added a few units which are used in other libraries e.g. Django, mostly derivatives of CRS units (e.g. US Survey miles). I may have cast the net too widely there - it's unlikely anyone will want to use mpd to analyse a trajectory in EPSG:4168 (unit: Gold Coast Foot) or EPSG:3167 (unit: British chain (Sears 1922 truncated)) - but I figured it would do no harm to cover even the obscure ones, and you never know.

So that's why it doesn't necessarily match pint or geopy. I would have to have a deep think about pint and whether that's the best way to handle units in dataframes (especially as it seems to be at odds with the new pandas pyarrow backend?). I'd still class my abilities with python as very much intermediate, so it might take me a bit to get my head around it! But would be very happy to have a go at implementing it differently if pointed in the right direction.

[raybellwaves]

Thanks. I am not sure if pint handles all the units mpd now can. I started by looking at geopy but quickly realised the limiting factor was the need to be able to handle whatever units the crs of a dataset might be in. Geopy doesn't handly them all. I couldn't actually find a list of CRS units anywhere, so I wrote a short script to transform a test dataset into every CRS in the proj database in turn, and extract each unique unit. That was the base unit list, and I just kept all the names which were extracted from that. I then added a few units which are used in other libraries e.g. Django, mostly derivatives of CRS units (e.g. US Survey miles). I may have cast the net too widely there - it's unlikely anyone will want to use mpd to analyse a trajectory in EPSG:4168 (unit: Gold Coast Foot) or EPSG:3167 (unit: British chain (Sears 1922 truncated)) - but I figured it would do no harm to cover even the obscure ones, and you never know.

So that's why it doesn't necessarily match pint or geopy. I would have to have a deep think about pint and whether that's the best way to handle units in dataframes (especially as it seems to be at odds with the new pandas pyarrow backend?). I'd still class my abilities with python as very much intermediate, so it might take me a bit to get my head around it! But would be very happy to have a go at implementing it differently if pointed in the right direction.

Thanks for sharing your thoughts. Nice work.

[anitagraser]

I'm planning to merge the #295 PR and do do the release on Monday if nothing else comes up.

[bamacgabhann]

I think I have the tutorial notebooks ready, added examples in 1 and 2. I want to look at them again tomorrow with fresher eyes for a final check, but I'll be able to push them before Monday. Should I push to #295 and keep everything together, or do a separate PR for the notebooks?

[anitagraser]

Feel free to push to #295 if you are happy with the notebooks by Monday. Otherwise, we can merge the notebook changes later.

[anitagraser]

@bamacgabhann Thank you for getting #295 ready to merge. As noted in the closing comment, there are still the topics raised in #308 regarding unit conversions in get_length() and distance() (and potentially other methods that should support this new feature. If you're already on it, let's wait with the release and include these.

[anitagraser]

I'm going through the notebooks now to see if everything there works as expected and if we should update some of the examples.

[anitagraser]

Thinking of how to handle the TimeZoneWarnings popping up with Geolife examples

[anitagraser]

import warnings
from movingpandas.trajectory import TimeZoneWarning
warnings.filterwarnings("ignore", category=TimeZoneWarning)

[anitagraser]

I've been thinking of changing the version name from 0.16rc1 to 0.16.0 to be more in line with most other libraries. Do you see any downsides to this?

[raybellwaves]

good idea

[bamacgabhann]

I have some time later this afternoon and evening if there's anything I can help with. Will look at tests and column names, if there's anything else I can do let me know.

[anitagraser]

@bamacgabhann That sounds great. I'll get 0.16.0 out now and then update the movingpandas-examples repo. We can introduce the column name automagic in 0.16.1 or 0.17

[anitagraser]

TrajectoryCollection.add_speed et al. also still need unit support #308

[anitagraser]

0.16.0 is out and I've updated the notebooks in the example repo as well as the website.
The biggest discovery was that we still need unit support in trajectory collections. Besides that, some edge cases of the improved plots don't work perfectly yet but no major issues overall 🥳