If I'm correct the main difference with TimestampedGeoJson is that data points have a start time and an end time, whereas TimestampedGeoJson only allows a single timestamp.

Two thoughts:

• I'd rather not have two plugins that have very similar, but slightly different functionality. That will make it harder for users to discover which Folium features they need. And gives us more code to maintain with little added benefit in terms of features.
• TimestampedGeoJson is not great in terms of maintainability, since it contains quite some Javascript logic that I'm not keen on.

I'm thinking, would it be possible to provide a single timeline/timestamped GeoJson plugin to our users? Maybe we can replace the internals of TimestampedGeoJson with your change, and add some Python logic to convert timestamps and durations to start and end dates?

Additionally, TimestampedGeoJson contains some features like popup support and pointToLayer definitions. Would we need to add the same in this new plugin?

What do you think?

I will implement popup support and pointToLayer.

To merge the two would be much better indeed. I will need to find a strategy for that as the underlying leaflet plug-ins are different. timedimension uses a layer global duration parameter to indicate how long a feature stays visible, whereas leaflet-timeline.js uses a per feature end field in the geojson. Do you have any ideas how to unify these two? I'd prefer not to switch between two different leaflet plugins depending on the parameters passed.

About that unmaintainable Javascript, were you talking about the extends? I was planning to do something similar to the leaflet-timeline.js plugin. The original plugin removes from the map the features that are not active at a certain time. I was thinking about using an extends construction, so that it instead applies a different style to active and inactive features. (Similar to how google timeline works).

This will give the user the choice between hiding an inactive feature and highlighting active features. Any thoughts on this?

@Conengmo I made some progress, but I am not really happy with it. There is a big underlying difference between the Timedimension and timeline plugins, in terms of the exact format of the geojson you'd feed the plugins. Timedimension allows a times parameter, which for a compound feature like LineString means the feature itself is split up into multiple geometries. For timeline you'd split this into different features each with their own geometry and start and end values.

I managed to create a jq script that will translate from the Timedimension format to the timeline, but I think it is too complicated. I am pretty sure there are some edge cases in which it will break. It also adds a dependency on jq, which somehow breaks the tests.

I think I will take a step back and rewrite as follows:

1. If the user passes a get_interval function, use the timeline implementation.
2. If the geojson contains a times property use the Timedimension implementation.
3. If the geojson contains start and end properties use the timeline implementation.

I do like the extra user flexibility of having JsCode parameters for point_to_layer, style and on_each_feature.

This will at least ensure backward compatibility.

However, you may consider this too complicated to maintain and confusing to the user. If so, I can just give up on the project. Let me know your thoughts.

@Conengmo can you have look? I am not sure whether the advantages of having one plugin for both use cases outweighs the additional maintenance complexity. Another approach would be to have two classes in timestamped_geo_json: TimestampedGeoJson and TimeIntervalGeoJson.