This line and the other similar lines should really use plot_type rather than hard coded value about weewx-polarwindplot HOT 6 CLOSED

I wanted to discuss this and some other code that sets values dependednt on the plot type (the number 20 and 22 ring a bell somewhere). We really shoudl be able to make this work without reference to plot type. In this case we are just rendering the polar grid and that should be essentially the same for all. Sure the ring labels are different from plot to plot but that is handled elsewhere. From memory this was one of those instances where I did not fully understand the intent and given a lack of time I left some dysfunctional or porly written code.

Shoudl be easy enought to resolve with a littl emore considered thought.

from weewx-polarwindplot.

I tidied the 20/22 funny number things in the ring drawing here
[https://github.com/gjr80/weewx-polarwindplot/commit/00234f4739953fa66381c720541e1714ab0c346c#diff-0a3d7f9b5216d7a8ed1f4dc2b7dcb042]

I have simplified the code (but left old commented out for now). Some of those magic numbers actually come down to single parameter (the number of rings).
What complicates things is -
Trail/spiral/scatter have 5 equal rings
Rose is the odd one as it has 5.5 rings - 5 equally spaced outer rings and the center Zero that is the radius of half a ring.

This is why we now have
if plot_type == "scatter" or plot_type == "spiral" or plot_type == "trail" : no_of_rings = 5 centre_ring = 0 else : no_of_rings = 5 centre_ring = 0.5

Before you grab my latest code if you look at a trail/spiral/scatter plot you will see 5 rings but the inner one is wider than the rest, that was the bug that made me look at this bit of code.
Latest code draws 5 equally spaced rings for trail/scatter/spiral and leaves rose functioning (correctly) as before

from weewx-polarwindplot.

This issue was raised because the call to
self.render_polar_grid()
did not have direct access to plot_type without some bigger code changes so I just hard coded the value to get things working.

from weewx-polarwindplot.

OK, now I am seeing the issue. Perhaps if we take the approach that the plot rings (think I have referred to them as range rings or speed rings at various times) are the five rings that are common to all plots. The 'bullseye' is effectively another part of the windrose data being plotted. So we can pull that out of the render_polar_grid method and put it elsewhere in the PolarWindRosePlot class though am not sure how feasible this will be (am sure it is doable but it could be messy). The intent I always had for the render_polar_grid method was that it rendered the polar grid onto which we plot the data, so this approach will follow that intent.

Let me see how I go with this, more thought required.

from weewx-polarwindplot.

Clearly on the wrong track again. Just realised the rose rings are equally spaced from the outside of the bullseye, for some reason I had it in my mind they were equally spaced from the polar plot origin. Also thought that render_polar_grid was plotting the bullseye, clearly it's not.

Did a quick refactor so that render_polar_grid accepts a parameter bullseye that is a float in the range 0 to 1 representing the width of the bullseye as a proportion of the polar plot radius (if you like bullseye is the same as the old centre_ring or delta variables). bullseye has a default value of 0. So calling render_polar_grid with no parameters will give a grid with no bullseye, calling it and passing 0.1 gives the rose plot with the bullseye as it is now.

I have made a couple of other changes that will facilitate giving the user control over the number of range rings, it will be a simple step to also give control over the bullseye size.

from weewx-polarwindplot.

Refactoring of the render_polar_grid method at commit 0445529 has addressed this issue, there maybe some secondary issues flowing from the extensive refactoring but they will be picked up in the normal test process.

from weewx-polarwindplot.