submitting remote sensing tutorial

[cmbarton]

This has been run through the MD linter to check for formatting.

[petrasovaa]

@cmbarton This includes a lot of images/graphics taken from other sources. I don't think we can use those here unless their copyright allows it or you have explicit permission from authors.

BTW, the freeze is not needed anymore.

[cmbarton]

@cmbarton This includes a lot of images/graphics taken from other sources. I don't think we can use those here unless their copyright allows it or you have explicit permission from authors.

We're OK with this. It's only the images in the intro section. I checked them all to make sure they are open access or public domain, and made a few adjustments from my original used for the workshop. I've also added attribution where possible.

BTW, the freeze is not needed anymore.

Good to know.

[veroandreo]

Hey, @cmbarton! Thanks for the tutorial, I like how colorful the images are. I have some general observations that I detail below:

• Convert bullet points into actual paragraphs, i.e., in most cases, the text already flows as a paragraph, so no need for bullet points. Let's use them only when needed.
• We need a thumbnail for the main page:
  
• Some of the result images appear too big to me, while the screenshots where people actually need to read instructions (i.e., GUI tabs) seem too small in comparison.
• In the last section, you mention a lot of other great functionality for remote sensing in GRASS 🤓, it'd be nice to add links there, so people can immediately identify the actual GRASS tools to run those analyses.
• All in all, I think we should classify this tutorial as beginner, as it shows basic remote sensing tasks. It'd be better to keep the intermediate and advanced tags for other remote sensing analyses like image rectifications, classification, OBIA, time series, etc.

[cmbarton]

Thanks for the review @veroandreo

• Convert bullet points into actual paragraphs, i.e., in most cases, the text already flows as a paragraph, so no need for bullet points. Let's use them only when needed.

I've changed a few where it seemed appropriate. I like the bullets for other places, however, as I think it makes it easier to follow the info and steps. A matter of style preference perhaps. Some people like them and others not so much.

• We need a thumbnail for the main page:
  Didn't know about that. I guess Anna added it to another tutorial. I've made one for this tutorial and will commit it

• Some of the result images appear too big to me, while the screenshots where people actually need to read instructions (i.e., GUI tabs) seem too small in comparison.

I'm not sure why they seem odd sized to you. They are fit into columns or page width. In any case, anyone can click and open any image to get a full sized version if the default one is too small.

• In the last section, you mention a lot of other great functionality for remote sensing in GRASS 🤓, it'd be nice to add links there, so people can immediately identify the actual GRASS tools to run those analyses.

I'm adding a bunch of links

• All in all, I think we should classify this tutorial as beginner, as it shows basic remote sensing tasks. It'd be better to keep the intermediate and advanced tags for other remote sensing analyses like image rectifications, classification, OBIA, time series, etc.

We need a better definition of what tags mean. You (and Anna) are referring to introductory or 'beginning' remote sensing analyses. By focusing on visualization, that is indeed what this tutorial does, with classification, feature detection, etc. being more advanced forms of remote sensing. To me (and many others), "beginner" refers to a person--a GIS beginner--rather than to an analysis. "Beginning" could refer to an analysis, but could also be confusing. So this tutorial to me is introductory remote sensing analysis for intermediate or advanced GIS users (i.e., people), rather than intermediate or advanced remote sensing analysis. I've changed the title and tags to be more clear about meaning. But for tags to be widely useful, we will need to define what they mean and how to express them.

[veroandreo]

I made some images smaller and added the lightbox class so they become clickable, converted some bullet point text into paragraphs, fixed LandSat --> Landsat as per https://www.usgs.gov/landsat-missions, and changed category to beginner.

I think it's ready to merge now. Thanks @cmbarton !!

[cmbarton]

Vero, I appreciate any suggestions and comments. However, I request that you do not unilaterally alter my tutorials without my knowledge or approval. I've spent many hours on developing these. While some of the alterations you made are helpful (adding Lightbox), others are concerning (changing image sizes to look better on your flavor of Linux might or might not affect how they look on other platforms), others are annoying (changing the styling I used because you don't like bullets). I've been happy to incorporate some suggestions, and would happy to incorporate others. But all of them are stylistic, and in some cases a matter of personal preference. They are not coding bugs. This is copyrighted intellectual property that you altered without author authorization. Please refrain from doing this in the future.

[wenzeslaus]

About editing what is in the pull request, the creator of this PR "allowed edits by maintainers" when creating the PR and this is indicated for each user on their pull request:

About copyright, this repository specifies the content licensing in its readme and license files. The licensing allows further use and modifications just like many open source licenses do (as defined by Four Freedoms of Free Software by Free Software Foundation, Open Source Initiative, or the Open Definition). While these licenses don't negate copyright (and they in fact use it to work), they allow others to alter copyrighted intellectual material without author authorization for the particular change because a general provision for that was already given by the author through the license. This allows the open source ecosystem to thrive. While there might be funding mandates or other forces in play, from this repository perspective, no one is forced to adopt these licenses outside of this repository.

About modifying, people with write-level access to this repository were given trust by the broader community through the Project Steering Committee (see Governance) to be the gatekeepers and stewards of the content of each repository. It is their responsibility to keep content and style in the form and shape they see best fits the intended purpose as well as the style and content of other material. In the lack of written style guide and automatic checks, it is the existing content and the maintainers who determine the style.

About the specific changes, I'm not convinced the comparison with code is appropriate in terms of style being code style and content issues being coding bugs. The style is the representation to the user so it is really the first thing a user of the material deals with, so bad style can be a bug. However, even if we go with the code analogy, then we do enforce specific coding and formatting style in our code (in the other repositories), and so all maintainers and contributors give up their personal preferences about things like formatting and work under a common style.

As admin-level maintainer of this repo, I'm locking this thread and will be happy to continue this conversation privately. Everyone involved here has my private contact.