Region modifiers with '+' or '-' suffix

[23ccozad]

In GEMPAK, users have the ability to add '+' or '-' to the end of a string given to the GAREA parameter, which zooms in or out of the specified region. This PR makes this functionality possible for the area attribute of MapPanel

Description Of Changes

Checks for presence of '+' or '-' in area strings when drawing map. The number of pluses and minuses are counted. A plus is worth 1, and a minus is worth -1. The sum is called zoom and is passed to _zoom_extent.

_zoom_extent is a new method that takes an extent and expands or contracts it. This method isn't always perfect in that it does not take into account the projection. It works well for plate carree, but it's a bit off with the more distorted projections. See test_declarative_region_modifier_zoom_out.png for an example.

Additionally, two new tests are introduced: one for zooming in and another for zooming out.

Checklist

• Closes GEMPAK-style region modifiers #1589 and closes Declarative extent zooming in/out #1288
• Tests added
• Fully documented

[kgoebber]

Great PR! Took it for a quick spin and works great with some pre-existing scripts that use the declarative syntax.

The only thing I'm wondering, which is related, but not necessarily tied to this exact PR, is if we should publish all of the different valid area strings. I know all of these areas were ported from GEMPAK, but even then they were hard to find there. It might be useful to have a link within the doc-string for the area attribute that has the list of names and lat/lon extents as there are potentially many useful ones we have defined, but that you would be hard pressed to know about. I wouldn't want to just list them as part of the doc-string because there are a lot and that would just overwhelm the page.

If we do want to go the route of a separate page, would it be worth having a small static image associated with each area to better illustrate the extent?

[dopplershift]

This looks pretty good. One thing jumps out, though: I wonder if this might work better if we did it through traitlets validation. This would allow us to give users a good error when they try to set the extent rather than failing at draw time.

If this works out, it might show us a path forward on validating some more traits.

[23ccozad]

The only thing I'm wondering, which is related, but not necessarily tied to this exact PR, is if we should publish all of the different valid area strings.

The docs say "For a CONUS region, the following strings can be used: ‘us’, ‘spcus’, ‘ncus’, and ‘afus’. For regional plots, US postal state abbreviations can be used." But now having seen declarative.py and knowing that there are over 400 valid strings that can be used, I've had the same thoughts. If there's nothing in the docs about them, they're probably not being used. I'll be thinking about how we can add this to the docs, hopefully in a simple way.

[dopplershift]

Looks like we're on a good path here, I just found some things that I think can simplify it.

[dopplershift]

Geez, that's twice zoomed in? I'll have to look at original vs. 1 zoom.

[dopplershift]

Found a few other stylistic changes that seem to clean things up. Especially using f-strings in the exceptions.

[dopplershift]

Technically this try...except would catch any uncaught AttributeError happening anywhere while executing that line. While this definitely works, and a weird AttributeError bubbling up is unlikely, I feel like explicitly checking for None (which is what is documented as the behavior for "no match" in the docs) would be better style:

Suggested change

	try:
	region, modifier = re.match(r'(\w+)([-+]*)$', area).groups()
	except AttributeError:
	raise TraitError('"' + area + '" is not a valid string area.')
	match = re.match(r'(\w+)([-+]*)$', area)
	if match is None:
	raise TraitError(f'"{area}" is not a valid string area.')
	region, modifier = match.groups()

[23ccozad]

Gotcha, didn't think about other errors coming up.