Update quickstart documentation so that HRV channel is not loaded

[simonrp84]

The quickstart guide currently says:
global_scene.load([0.6, 0.8, 10.8])
But, for SEVIRI, this will load the HRV channel and not VIS006. This PR corrects the quickstart so that VIS006 is loaded as expected.

• Fully documented

[codecov]

Codecov Report

Merging #1886 (79b5c77) into main (fc66d32) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1886   +/-   ##
=======================================
  Coverage   93.95%   93.95%           
=======================================
  Files         285      285           
  Lines       43754    43754           
=======================================
  Hits        41108    41108           
  Misses       2646     2646           

Flag	Coverage Δ
behaviourtests	4.73% <ø> (ø)
unittests	94.62% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Help us with your feedback. Take ten seconds to tell us how you rate us.

[coveralls]

Coverage remained the same at 94.571% when pulling 79b5c77 on simonrp84:fix_qs_docs into fc66d32 on pytroll:main.

[djhoese]

This is a difficult change to accept because this section is specifically meant to show how wavelengths can be used in loading. The next section of documentation specifically says "You can load by wavelength (see above) or by name", this change breaks that. Is there a wavelength that can be requested that would load the original expected channel (like a wavelength just outside HRV but still inside VIS006's range)?

Otherwise, are the rest of the instructions in the quickstart valid for HRV or will they fail when HRV is used? If not, should the output just be updated to reflect what is in HRV? Otherwise, should we change the quickstart to not use SEVIRI data because of this complication/complexity?

[gerritholl]

The real problem here is Satpys logic to implicitly load HRV when asking for 0.6 µm, which may or may not be what users want. Thereby Satpy doesn't even show a warning that the request is ambiguous. Better would be a (global) config where priority con be configured between different behaviours in case of ambiguity: guess without warning, guess with warning, or error. When guessing, it could be the channel with the narrowest band, channel with the highest spatial resolution, or something else yet. See the dedicated issue #1721.

[djhoese]

Sure but that doesn't change that this PR requires more changes than it has.

[djhoese]

What about changing 0.6 to VIS006, but leaving the others. Then update the next sentence below this to something like "As shown above, Satpy allows data to be loaded by wavelength in micrometers or by name. If multiple variables match a wavelength or name then the highest (finest) resolution will be chosen (ex. SEVIRI HRV and VIS006 channels are both match a wavelength request of 0.6)."

[mraspaud]

I suggest we just use other channels in the example to avoid the ambiguity and fix this bad example quickly. Then we need to address the underlying problem, but in another PR

[djhoese]

pre-commit.ci autofix