Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JOSS Review] Paper/documentation comments and suggestions #19

Closed
elbeejay opened this issue Apr 26, 2021 · 5 comments
Closed

[JOSS Review] Paper/documentation comments and suggestions #19

elbeejay opened this issue Apr 26, 2021 · 5 comments

Comments

@elbeejay
Copy link

The eemont package is clearly a useful addition to the GEE API and improves the functionality and ease of use of Google Earth Engine, so congratulations to @davemlz for creating a useful package for the broader gee community.

That being said I think both the documentation and the JOSS paper could make a stronger case for the benefits of the eemont package. From the paper and documentation alone is not obvious to me why I would pick up eemont - potentially simpler code than the standard Earth Engine API? I would suggest showing the necessary code without eemont to perform the same analysis for one or two of the examples in the Features section of the documentation alongside the eemont implementation. Having a direct comparison of the (presumably longer) standard Earth Engine code required to accomplish the same task you can perform with eemont in just a few lines provides a much more compelling reason for someone who sees the package to use it.

In a similar vein, in the context of the paper, I think it would at least be beneficial to state the number of lines required to perform the process in the example given with and without eemont. This way a reader of the JOSS paper will be able to more intuitively grasp the value of using eemont. Even better, if there is some estimated "average" simplification or line-shortening accomplished by using eemont that'd be great to include, although I can understand that such a quantification may be impossible due to the diversity of remote sensing applications and processes eemont can be used for.

Regarding the "State of the field", I believe there are a handful of packages out there that provide additional functionality on-top of the standard Earth Engine API (e.g., geemap, geetools, some packages by GitHub users fitoprincipe and samapriya, just to highlight a few). I think the paper should mention more of these other tools and packages, as eemont can likely improve users' experiences with them as well (at least where calls to Earth Engine are made). Furthermore it would provide a good place to highlight the unique niche eemont fills amongst other tools and packages that build off of the standard Earth Engine API.


This comment relates to the ongoing JOSS review of this package, comment pertains to the "Documentation" and "Software paper" sections of the JOSS reviewer guidelines:

A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?

A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?

State of the field: Do the authors describe how this software compares to other commonly-used packages?

@davemlz
Copy link
Owner

davemlz commented Apr 26, 2021

Hi, @elbeejay!

Thank you very much for your comments and suggestions!

I really like your ideas for the documentation and also for the paper! I will work on them and I'll let you know when they're ready.

Thank you very much again!

Cheers!

davemlz added a commit that referenced this issue Apr 27, 2021
@davemlz
Copy link
Owner

davemlz commented Apr 27, 2021

Hi, @elbeejay!

I have updated the examples of the features in the README and also in the Docs for the upcoming version. The new examples now show the comparison between using just the GEE Python API methods and using eemont methods.

Now I'm going to work on the paper with your additional suggestions!

Thank you!

@elbeejay
Copy link
Author

Looks great, I think it makes the package very attractive for someone that stumbles upon it while trying to pick up the GEE Python API

davemlz added a commit that referenced this issue Apr 30, 2021
@davemlz
Copy link
Owner

davemlz commented Apr 30, 2021

Hi, @elbeejay!

I have modified the paper following your suggestions. I have added the comparison with the GEE Python API, and also two new sections: one for the GEE Community Developer Resources and one for the integration with QGIS (both for the state of the field).

Cheers!

@elbeejay
Copy link
Author

elbeejay commented May 1, 2021

Great, I took a look at proposed changes in #21 and I think those are very good suggestions for changing some of the language and phrasing used.

@elbeejay elbeejay closed this as completed May 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants