Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AnimatedPolarPlotterly default colors #1137

Open
Antoine101 opened this issue Mar 3, 2025 · 3 comments
Open

AnimatedPolarPlotterly default colors #1137

Antoine101 opened this issue Mar 3, 2025 · 3 comments

Comments

@Antoine101
Copy link

Antoine101 commented Mar 3, 2025

Hi,

I am finally checking the newly implemented AnimatedPolarPlotterly class I had requested end of last year.
It seems to work well although I haven't fully checked it yet.

There seems to be differences with other plotters regarding default track colors.
In your first tutorial An introduction to Stone Soup: using the Kalman filter, default colors are red dashed line for ground truth, blue dots for measurements and purple dots+line for tracks. With AnimatedPolarPlottery, the track is plotted with red dots+lines by default.

Looking at the source code (plotters.py script), I noticed that AnimatedPolarPlotterly gets most of its plot methods (plot_measurements and plot_tracks among others) from the PolarPlotterly class, while the AnimatedPlotterly class has its own methods.

The uncertainty argument is not implemented/processed in the plot_tracks method of the PolarPlottery, and the tracks are not styled like in the plot_tracks method of the AnimatedPlotterly class.

It's an aesthetic detail but it got me to think about the logic behind the plotters implementation. Can you please clarify what the intended strategy is? Shouldn't all the plotters share similar methods? Or is it just temporary and you have planned to homogenize everything in the future?

I would be happy to contribute when this is clarified.

Thanks in advanced.

Antoine

@BodleianLibraries3YP
Copy link

Just offering some clarification with no answers:

In your first tutorial An introduction to Stone Soup: using the Kalman filter, default colors are red dashed line for ground truth, blue dots for measurements and purple dots+line for tracks. With AnimatedPolarPlottery, the track is plotted with red dots+lines by default.

^ Perhaps best to clarify some things here. Ground truths have a list of colours that get looped through. I.e. if there are 3 targets, 3 each one has a different colour, up to something like 10 when the colours cycle round again. The dashed line stays the same for all ground truth targets. It shouldn't be too hard to make AnimatedPolarPlottery match this colour scheme.

Blue dots for measurements is always the same (unless one purposefully plots clutter as yellow triangles) because we don't know which target, if any, each measurement belongs to.

Tracks are treated the same as ground truth in that each track has a different colour, up to the something like 10 colours. AnimatedPolarPlottery probably cycles through them slightly different to the other plotters?

The uncertainty argument is not implemented/processed in the plot_tracks method of the PolarPlottery, and the tracks are not styled like in the plot_tracks method of the AnimatedPlotterly class.

^ Gaussian uncertainty is mathematically difficult to plot in polar. The standard approach would be to transform the Gaussian Cartesian ellipse into polar space, which creates a sort of banana shape. This is easiest to replicate using particle sampling/monte carlo, but is computationally expensive.

@sdhiscocks
Copy link
Member

It's an aesthetic detail but it got me to think about the logic behind the plotters implementation. Can you please clarify what the intended strategy is? Shouldn't all the plotters share similar methods? Or is it just temporary and you have planned to homogenize everything in the future?

So the plotter classes have grown naturally over time, from multiple authors, and such are certainly a bit messy at the moment. It would be good to get more consistent output, and also standardise better the various methods, both to make them more interoperable, and reduce code duplication. We don't have any plans for this at the moment, but it certainly would be a welcomed contribution 👍

@Antoine101
Copy link
Author

Indeed, PolarPlotterly plot_tracks method is not as complete as AnimatedPlotterly's equivalent.
I can start thinking about some improvement code work. I will be busy in the coming few weeks but after that I'll have more free time.
Do you have some kind of doc or diagram that explains the relationship between all these classes?
Are there some guidelines to keep in mind?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants