MIN: Update links/references to Spyder to point to new website, and minor opportunistic cleanup

[CAM-Gerlach]

Hey, I'm a member of the Spyder IDE core dev team (as well as a MS grad student in atmospheric sciences at UAH), and we're really happy you have such nice things to say about the IDE! Per spyder-ide/spyder-docs#39, we've been updating references to Spyder's ancient, un(able to be )maintained PyPI/PythonHosted docs (which will soon be finally removed, so as to prevent the user confusion that has resulted) to point to our modern website, with our new docs as well as information and updates about Spyder.

I happened to come across this project when looking for modern alternatives to solo3 (which was listed as "legacy" by NCAR but had no stated direct replacement), and noticed the mention of Spyder with the old link so I figured I'd update it (as well as do some grammar fixes and cleanup in the lines I'd already touched while I was at it).

Also, somewhat OT but I couldn't find it anywhere in documentation—how does this project compare to the more popular PyART, given they are both Python packages with outwardly similar goals—i.e. why might I use wradlib over PyART, and what is the rationale for actively maintaining two separate projects? Thanks!

[kmuehlbauer]

@CAM-Gerlach Thanks for the heads-up on the Spyder project.

I added two remarks and like to hear @heistermann on that.

[kmuehlbauer]

I would stick to "We recommend to install..." but have no strong opinion.

[kmuehlbauer]

To my knowledge common latin abbrevations like i.e. or e.g. do not necessarily need to be italicized. If we decide to change this here, we need to check the whole docs for consistency. @heistermann What do you think?

[CAM-Gerlach]

I would stick to "We recommend to install..."

This isn't grammatically-correct English, which is why I changed it. Another clean and grammatically correct alternative would be ``"We recommend installing..."; if you prefer that for some reason I'm happy to change it.

If we decide to change this here, we need to check the whole docs for consistency.

Great point; I didn't really think that through (especially since my intent both here and in #6 was not to affect anything related to style or content). I'd generally used that convention in my own writing, but its a bit of a holdover from a bygone era, as they have been well-accepted into the language in contemporary informal discourse. I'll revert it now.

[kmuehlbauer]

@CAM-Gerlach "We recommend installing..." sounds good. As non-native speaker it's always hard to get it all correct, thanks for addressing this.

[CAM-Gerlach]

Sure; doesn't make any difference to me but if its clearer to a non-native reader, then I'm all for it.

I'm the only English native on the Spyder team and have a experience in technical writing and tutoring non-native-English-speakers, so I tend to pick up quickly on the common quirks of such writing and can sometimes even tell someone's native language by how they write. On the other hand, I can sometimes use patterns, constructions and idioms that might be confusing or unfamiliar to a non-US audience, so as the maintainer of the Spyder docs, blog, media platforms, etc. I'm glad to have a diverse array of people from all around the word looking at my writing to make sure it makes sense.

[kmuehlbauer]

Also, somewhat OT but I couldn't find it anywhere in documentation—how does this project compare to the more popular PyART, given they are both Python packages with outwardly similar goals—i.e. why might I use wradlib over PyART, and what is the rationale for actively maintaining two separate projects? Thanks!

@heistermann Will surely give his opinion on that later. Here just my 2 cents.

How do you measure popularity? Conversations with colleagues, references in literature, talks in conferences, github stars/forks, download statistics (pypi, conda)? For the latter the download count is similar (PyArt leading with about 5-10%).

You might use wradlib over PyArt if you want to custom tailor your processing workflow without the need to use a data model (PyArt radar object). And this is also the main difference between wradlib and PyArt, as wradlib has no data model at all (with respect to weather radar data).

The reason to maintain multiple packages (just to name BALTRAD as another one) is, they serve different purposes (and sometimes different audiences). The good thing is, that we know each other well and collaborate as a community (https://openradarscience.org).

[CAM-Gerlach]

@kmuehlbauer Thanks for the detailed explanation! I'll definitely keep wradlib in mind in my future endeavors, particularly as I'm currently taking a course in advanced applications of dual-pol radar. We primarily use the non-free-software GR2AE for its convenience in data interrogation, but also use solo3, PyART, etc.

Are you aware of any actively maintained tools that fill the rather large niche currently occupied by the proprietary GR products (i.e. offering at least proper display in native polar coordinates, interactive browsing of data and an at least passable UI/UX for efficient use) that are free software? I looked into ARTView but it appears to be no longer maintained, and the UI/UX looked somewhat questionable (though not unusable); solo3 has the same issues only more so.

How do you measure popularity? Conversations with colleagues, references in literature, talks in conferences, github stars/forks, download statistics (pypi, conda)? For the latter the download count is similar (PyArt leading with about 5-10%).

A very good and valid question, and I didn't mean to impugn Wradlib in any way by my above comment; my impression was perhaps somewhat hasty. To directly answer it Github stars and issues/PR activity at first glance (which PyART has 2-5x of), download stats if provided (I didn't see them), and particularly in this case papers, conference talks and colleagues/professors (at least here in the US, all I hear is PyART, PyART, PyART talking to my peers, from professors, at AMS conferences, and in terms of what people use for their research here). However, with regard to the latter I guess that's probably pretty biased since PyART development is based in the US, while Wradlib is not.

Spyder is in an interesting place there as well, since Jupyter is the big craze here right now that everyone's using/talking about while Spyder is much less common at least in our field here in the US, yet it has similar Github stats in most respects and the great majority of its users are from Latin America, East and South Asia, the Middle East, and Europe; its also hard to measure download stats since it comes built-in to Anaconda (which has ~6 million downloads) as one of its flagship IDEs, but its hard to say what percent actively use Spyder...5%? 25%?

[heistermann]

Looks good - thanks @CAM-Gerlach for sorting this out, and thanks @kmuehlbauer for clarifying the role of different packages in the https://openradarscience.org community!

[CAM-Gerlach]

Thanks @heistermann and @kmuehlbauer ! Given this is done, I'll do the last blocked items in #6 now.

[kmuehlbauer]

@CAM-Gerlach Concerning your questions about data visualisation, I can't give a profound answer. There is indeed a lack of tools in this field, especially for display of weather radar data.

For fast (opengl powered) data visualisation (mostly 2D, but also 3D) I've been using VisPy. But you need a lot of customised code and also the UI is only as good as you program it. Currently I'm reviving some of my old code to display radar volumes (as single PPI, volume PPI, gridded volume, and timeseries). I'll make it available when I have a prototype.