Using class vs non class scalebar option with the same input parameters produces two different sized scalebars where one must be incorrect

[hamilton-dylan]

I found that something gets distorted between scale_bar and ScaleBar. We had to transition from using scale_bar to ScaleBar because we needed to set zorder on the scale bar. All other code is running the same except for that difference. I will drop snippets of the code that we use for each case just to be a little more clear. I have also provided images showing how different the output is for these two cases. I think that the output of scale_bar is the accurate one, but I'm going to send some data to another machine with GIS software to try and confirm that later.

Do you have any idea what could be causing this issue?

scale_bar case -

        scale_bar(
            ax=self.ax,
            location=location,
            style=style,
            text={
                'textcolor': 'white',
                'stroke_color': 'black',
                'stroke_width': 1,
                'fontsize': 12,
            },
            bar={
                'projection': projection,
                'unit': unit,
                'minor_type': 'first',
                'major_div': 2,
                'minor_div': 4,
                'max': maxScalebar
            },
        )

ScaleBar case -

        # we have to initialize the class so that we can call set_zorder on it
        scalebar = ScaleBar(
            location=location,
            style=style,
            text={
                'textcolor': 'white',
                'stroke_color': 'black',
                'stroke_width': 1,
                'fontsize': 12,
            },
            bar={
                'projection': projection,
                'unit': unit,
                'minor_type': 'first',
                'major_div': 2,
                'minor_div': 4,
                'max': maxScalebar
            },
        )

        # we need to set the scalebar zorder to 200 to ensure that it is on top of all layers, including inlays
        scalebar.set_zorder(200)
        self.ax.add_artist(scalebar)

using scale_bar

using the class, ScaleBar

[hamilton-dylan]

It looks like the ScaleBar version is actually the more accurate one. I verified the distances via a third party GIS software (QGIS).

[moss-xyz]

@hamilton-dylan that is decidedly odd behavior, considering ScaleBar just calls scale_bar() when add_artist() is used! I will take a look and get back to you, apologies for the bug - my testing prior to release did not reveal the same issue, but clearly something is up.

If you can share any more code/pseduo-code related to this, that would help me immensely; otherwise, I would appreciate at least knowing what projection you are working in, and the rough geographic boundaries of your example maps above^.

On the z-order point: that was also raised in #9; I didn't expect it to be an issue, but I can add that to my roadmap to fix as well.

[moss-xyz]

One thing I'm noticing just reading your code: It seems you are setting ax to self.ax - is this code nested within another object you've created?

[hamilton-dylan]

@moss-xyz self.ax is just setup that way because I created a class to handle the code, so ax is just being set on the class to make it a little easier.

To provide a little more context -

I am using a geotiff to initialize the plot using

self.src = rasterio.open(base_raster_path)

followed by

        self.ax = plt.gca()
        rasterio.plot.show(self.src, ax=self.ax)

to get the raster onto the plot.

Another couple of things that I'm doing that I initially thought may be behind this issue is increasing the resolution of the image via -

        self.fig = plt.gcf()
        width, height = self.fig.get_size_inches()
        self.fig.set_size_inches(width * size_multiplier, height * size_multiplier)

However, that does not appear to actually change the described behavior (scale_bar is still larger than ScaleBar for me even without this code running).

It is probably unrelated to anything, but I am also doing -
self.ax.set_axis_off()
To get rid of tick marks on the output. I did not test without running this.

Here is the full function that shows how we're setting most of the inputs

    def add_scale_bar(self, width_percent=0.15, scale_size_multiplier=660, location='upper right', style='boxes', projection=3857, unit='ft'):
        """
        Add a scale bar to the plot.

        Args:
            width_percent (float): Percentage of image width for scale bar (default: 0.15 = 15%)
            scale_size_multiplier (int): Multiplier for rounding scale bar size (default: 660 ft)
            location (str): Location of the scale bar
            style (str): Style of the scale bar
            projection (int): Projection EPSG code
            unit (str): Unit for the scale bar
        """
        if self.ax is None:
            raise ValueError("Base plot must be created first. Call create_base_plot().")

        left, right = self.ax.get_xlim()
        widthM = right - left
        widthFt = widthM * 3.28084

        maxScalebar = round(widthFt * width_percent / scale_size_multiplier) * scale_size_multiplier

        if maxScalebar == 0:
            maxScalebar = round(widthFt * width_percent / 100) * 100

        # scale_bar(
        #     ax=self.ax,
        #     location=location,
        #     style=style,
        #     text={
        #         'textcolor': 'white',
        #         'stroke_color': 'black',
        #         'stroke_width': 1,
        #         'fontsize': 12,
        #     },
        #     bar={
        #         'projection': projection,
        #         'unit': unit,
        #         'minor_type': 'first',
        #         'major_div': 2,
        #         'minor_div': 4,
        #         'max': maxScalebar
        #     },
        # )

        # we have to initialize the class so that we can call set_zorder on it
        scalebar = ScaleBar(
            location=location,
            style=style,
            text={
                'textcolor': 'white',
                'stroke_color': 'black',
                'stroke_width': 1,
                'fontsize': 12,
            },
            bar={
                'projection': projection,
                'unit': unit,
                'minor_type': 'first',
                'major_div': 2,
                'minor_div': 4,
                'max': maxScalebar
            },
        )

        # we need to set the scalebar zorder to 200 to ensure that it is on top of all layers, including inlays
        # scalebar.set_zorder(200)
        self.ax.add_artist(scalebar)

The projection that we're using is EPSG:3857.

Here is a link to the geotiff that I believe was used in my example. If its not the exact one, it is very close/similar.

https://www.dropbox.com/t/SF5O0JY6wfLHfGty

In case you cannot get the image, here is some of the location data from gdalinfo on the tif at the above URL -

Origin = (-8261606.174934637732804,5030718.297607493586838)
Pixel Size = (1.999914279240039,-1.999914279240039)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-8261606.175, 5030718.298) ( 74d12'54.98"W, 41d 7'28.09"N)
Lower Left  (-8261606.175, 5027482.436) ( 74d12'54.98"W, 41d 6' 9.25"N)
Upper Right (-8258866.292, 5030718.298) ( 74d11'26.37"W, 41d 7'28.09"N)
Lower Right (-8258866.292, 5027482.436) ( 74d11'26.37"W, 41d 6' 9.25"N)
Center      (-8260236.234, 5029100.367) ( 74d12'10.67"W, 41d 6'48.67"N)

Thank you for looking into this. The process that we're using is very complex, but I can try to provide any additional necessary context or code samples.

[moss-xyz]

The good news (for you) is that I seem to be able to recreate this issue! The bad news is that I have no idea what is causing it, so I'll have to look into it 😅 weirdly enough, it doesn't happen when I plot pure vector data using GeoPandas - just when I include raster data via rasterio or matplotlib.imshow()...

If you have any other hints as to the cause, please feel free to share!

One note: Am I understanding your code snippet for setting maxScalebar correctly, in that you want to force a major div value of 660 feet, and are calculating the nearest whole integer of major divisions based on that? That's an interesting pattern, I might look to bundle that into the package directly.

[hamilton-dylan]

I'm glad to hear that you were able to reproduce the issue. Unfortunately, I don't have any additional information that would likely be helpful at this point. I spent a little more time trying to reproduce it under different circumstances yesterday, but nothing useful came out of that.

You are correct about how we're using maxScalebar. We're trying to make the major divs a multiple of 660 in this case. It would be cool to see the pattern as an addition to the package 👍 .

I'm going to be continuing to work around this code for awhile longer, so I will keep an eye on this thread and report back if I do find any additional information about what's going on.

Thank you for your work, and for this package overall!

[moss-xyz]

I will be sharing findings as I reach certain checkpoints while debugging, for reference later as needed, apologies if this is annoying (no idea how many checkpoints will be needed to debug!)

So far I have ascertained:

• This issue does not occur when vector data is plotted - it seems to be specifically caused when using raster data
• It happens when either rasterio.plot.show() or matplotlib.pyplot.imshow() are used
• It happens with a different GeoTIFF, and it happens with a different projection than 3857
• It happens when an object is generated using ax.add_artist(scale_bar(..., draw=False)) instead of ax.add_artist(ScaleBar()), even though the latter actually utilizes the former!
• I am able to force an even more egregious difference between what the function plots and what the class method plots by plotting the same data on two axes, vertically stacked (see image - note the length has been set to 50% of the axis width (supposedly))
  • Does not seem to happen when the axes are horizontally stacked (i.e. multiple columns on one row)
  • Weirdly, this seems to happen even if the class method is above the function method for rendering in the stack (i.e. if I render the class to axis 0 first, then the function to axis 1 - the function still ends up larger!)

[moss-xyz]

My initial hunch is that the size (specifically, the width) of the Function axis is changing in between when the function is called and when the render actually happens - this would give an incorrect dimension size (ax_dim as calculated by _config_bar())

To test this, I set up some print() statements to print out the value of ax.patch.get_window_extent() and ax.patch.get_tightbbox() prior to running _config_bar(); for some reason, this actually runs three times for the class method, though I am not sure why.

Regardless, the output does show that the calculated width of the Function axis is 775 pixels (note: only relevant for my specific dimensions/set-up), versus the "correct" value of 458 pixels that the Object axis shows. The output also shows that the Function axis is rendered first, before the Object axis, even when the Object axis appears higher in the call stack - I assume this is because of how matplotlib handles placing an artist via a top-level call of ax.add_artist() versus ones that appears nested in a function?

I was then exploring where the change in axis dimensions might be coming from, so I compared the output of ax.patch.get_window_extent() to ax.get_window_extent(), which showed identical outputs, as expected (ax.get_window_extent() ignores ticks, labels, etc., so should be the same as ax.patch).

However, upon performing the same style of comparison between ax.patch.get_tightbbox() and ax.get_tightbbox(), I got an unexpected result - the scale bars appeared to be the same size once more! I also noted that the width of ax.get_tightbbox() was 494 pixels, not 775 as was returned by ax.get_window_extent(), and that the width could fall down to the correct value of 458 simply by moving the call to turn the axis off (ax.set_axis_off()) before the call to scale_bar().

This implies to me that the act of calling ax.get_tightbbox(), but NOT ax.get_window_extent() or ax.patch.get_tightbbox() forces a recalculation of the figure and axis somehow. A quick perusal of the function in matplotlib's source code did not reveal exactly why this is the case, however.

[moss-xyz]

It seems that this issue can be addressed by forcing matplotlib to draw the current plot / update the dimensions and placement of other artists before running _config_bar(), via ax.get_figure().draw_without_rendering().

As this only needs to run when it is the function being called, instead of the class method, it will be contained in an if block, so that the final addition looks like

# ...

if draw:
  ax.get_figure().draw_without_rendering()

bar_max, bar_length, units_label, major_div, minor_div = _config_bar(ax, _bar)

# ...

@hamilton-dylan before I push an update to pypi, would you be able to install/test a "fixed" version of this package that I upload here to GitHub, and confirm it works for you?

[moss-xyz]

@hamilton-dylan I went ahead and published the fix to the branch called func-class-reconcile - if you're able to, install and test it out and let me know if it fixes your problem! If not / you don't know how, just let me know and I'll get to it when I come online.

[hamilton-dylan]

@moss-xyz It would likely be difficult for us to test it without being able to install it via pip3, because everything we're running in python3 is running inside of a docker container. I'm glad to hear that you were able to track down the root cause and implement a fix! Well done!

[moss-xyz]

@hamilton-dylan You should be able to install the branch directly from GitHub, using pip, with the following code:

pip install git+https://github.com/moss-xyz/matplotlib-map-utils.git@func-class-reconcile

It has been a while since I've done this though, and I've never tried it on Docker, so let me know if this doesn't work for some reason, and I'll just upload the fix to pypi for you to install the normal way.

[hamilton-dylan]

@moss-xyz I was able to update our docker image to install the package like you described. I confirmed that running the same code that I was running before where one uses scale_bar and the other uses ScaleBar no longer results in two different scalebars 🥳 !

Both instances produced the same exact scalebar in the image below. Nice work! Thanks for taking care of that!

[moss-xyz]

Thank you for testing @hamilton-dylan - I've pushed v3.0.1, which just contains this fix, to pypi.

I've noted your two other feature requests, regarding zorder and fixing major division intervals - the former will definitely be in a 3.1.0 release that I'll try and do in August, and I will do my best to include the latter, but it might require a bit of a bigger rewrite of some logic.

Let me know if you have any other issues / feature requests / general comments! I'd also love to know how you came across this package, if you're able to share.