Polar Stereo projection : easing getting default tick marks and labels

[senesis]

Considering example NCL_conOncon_5 of the gallery, I am impressed by the fact that, while Ncl automatically sets relevant default tick marks, labels and gridlines for StereoPolar maps (see the Ncl code), you need a lot of code for doing the same with cartopy, and there is apparently no helper gv function for that. Am I right ?

[kafitzgerald]

Thanks for the question.

I'll confirm, but I don't believe the tick and label helper functions in geocat-viz work with non-rectangular projections at the moment. To your point from earlier issues, this should be more clear to users and based upon the names and descriptions of functions I too would assume they're more generally applicable than they are in practice. This dev work was before my time, but seems to have been pretty narrowly focused on supporting specific needs in the geocat-examples gallery and the documentation doesn't necessarily reflect this. Both the documentation and limited functionality are valid issues. I think we can probably expand the scope #210 to include this particular case as well, but if you'd like to open another one that works too.

You also make a good point in contrasting the amount of code and hit on some challenges and tensions there for GeoCAT. For many examples gallery scripts, the number of lines of code required and complexity of the scripts was greatly increased by trying to more closely replicate the specific formatting of the original NCL examples rather than achieve the same overall goals in a way more closely aligned with the intended use of the matplotlib and/or cartopy. The particular case you mention is one of those. There are some other reasons (for the greater number of lines of code) as well, I'll gloss over those for now.

Along those lines, something I think the GeoCAT team would be curious to hear more from the community about is on the relative value of replicating NCL visualizations, supporting similar use cases to NCL, porting over additional functionality, and minimizing code required. Obviously there are also some considerations on the development and maintenance side of things as well that play into decision making, but more input on the former would certainly be helpful.

[senesis]

I cannot pretend to be the voice of the community (and maybe getting its feedback should be organized beyond GitHub tools). I think that the baseline exclude porting additional functionality but includes to a large extent the three other goals you mention.