Kelly Kearney

I've been using an older version of this function for a few months now, and it's a great little utility, much more flexible than datetick. However, I noticed two small bugs with this release:

1) If you plot data that spans several years, then zoom in to a few-months range, a reference year will appear in the ylabel. However, when you revert to the original multi-year range, the reference year ylabel remains.

2) If datetick thinks there should only be one tick, the new version of tlabel will crash on tlabel>fixTicks line 1108. This is really due to buggy tick location calculations in datetick, and may only occur in older versions of Matlab (I'm running R2007a) since I believe datetick has been updated since then. This situation only seems to arise for a small subset of cases where data spans a year plus a few hours. Older versions of tlabel were able to handle this case.

Other than those two issues, great function, and I really like the new 'whichAxes' and 'reference' options.

This algorithm looks interesting, and I wanted to try to compare the computation time and results with Matlab's bufferm function (part of the Mapping Toolbox) and my own bufferm2 function (a modification on bufferm available on the FEX). I habitually use these functions to extend complex but non-self-intersecting polygons, usually the borders of various lakes, oceans, basins, etc. However, my tests (trying to buffer a simplified version of the Great Lakes) have so far failed to return a non-empty array. Stepping through the code, it seems the original polygon extension (lines 195-254) creates very interesting but unexpected modern-art scribble resembling the Lakes, which is then completely eliminated in the next step due self-intersection. Are there limitations to your algorithm that aren't mentioned here?

This function does seem a bit more limited than the functions I mentioned. It can only buffer outwards, not inwards. Also, it cannot handle NaNs in the polygon definition, which is the typical Matlab syntax to indicate a multi-segment polygon, both in plotting and the other polygon-related functions (mostly Mapping Toolbox functions). However, it doesn't rely on the Mapping Toolbox, which could be a nice advantage over bufferm and bufferm2. I'll withhold my rating until I determine the cause of my incorrect results.

This is a very useful function that does almost exactly what I was trying to do, and it should save me a lot of time. Thanks for making it!

I think, though, that it would be even more useful if you made two modifications:

1) The reference color of the bounded area should be set independently (as an RGB array), rather than being constrained to be a lighter shade of the corresponding line color. This would be particularly relevant for users preparing b&w figures for publication who, for example, might want to use two black lines and two different shades of grey for the bounded areas. The specific example I provided could of course be facilitated simply by allowing separate transparency parameters for each bounded area, but that still would not provide as much flexibility as some users might want.

2) The default behavior of 'legend' is to use shaded boxes that are the same colors as the bounded areas. Some users might prefer that the legend use lines of the same color and style as the corresponding data. It would be nice to have the option of using either. I believe this could be controlled from within boundedline.m by setting the 'IconDisplayStyle ' property of the 'LegendEntry' array of each patch to 'on' or 'off'.

Example code:
set(get(get(hPatches(1),'Annotation'),'LegendInformation'),'IconDisplayStyle','off')

Also, there appears to be a bug (using R2007b): adding a legend to a figure that was made using the 'alpha' option results in no legend and no bounded areas.

Fair result, good and fast script.