[REVIEW]: Geodata-Harvester: A Python package to jumpstart geospatial data extraction and analysis

[editorialbot]

Submitting author: @sebhaan (Sebastian Haan)
Repository: https://github.com/Sydney-Informatics-Hub/geodata-harvester
Branch with paper.md (empty if default branch):
Version: v1.1.2
Editor: @hugoledoux
Reviewers: @lukasbeuster, @martibosch
Archive: 10.5281/zenodo.8339817

Status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/db121dc1e185f35d06c1137f7d25f79c"><img src="https://joss.theoj.org/papers/db121dc1e185f35d06c1137f7d25f79c/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/db121dc1e185f35d06c1137f7d25f79c/status.svg)](https://joss.theoj.org/papers/db121dc1e185f35d06c1137f7d25f79c)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@lukasbeuster & @sjsrey, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review.
First of all you need to run this command in a separate comment to create the checklist:

@editorialbot generate my checklist

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @hugoledoux know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Checklists

📝 Checklist for @lukasbeuster

📝 Checklist for @martibosch

📝 Checklist for @sjsrey

[editorialbot]

Hello humans, I'm @editorialbot, a robot that can help you with some common editorial tasks.

For a list of things I can do to help you, just type:

@editorialbot commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@editorialbot generate pdf

[editorialbot]

Software report:

github.com/AlDanial/cloc v 1.88  T=0.15 s (602.3 files/s, 184289.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
HTML                            18           1388              0          13795
Python                          27           1085           2169           3940
Markdown                        29            902              0           2685
JavaScript                       1             35              6            300
YAML                            10             29             33            249
TeX                              1              5              0             60
Jupyter Notebook                 2              0            808             30
SVG                              1              0              0             16
CSS                              1              0              1              0
-------------------------------------------------------------------------------
SUM:                            90           3444           3017          21075
-------------------------------------------------------------------------------


gitinspector failed to run statistical information for the repository

[editorialbot]

Wordcount for paper.md is 895

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1016/j.rse.2017.06.031 is OK
- 10.1016/S1364-8152(01)00008-1 is OK
- 10.21105/joss.03168 is OK
- 10.5194/isprs-archives-XLVIII-4-W1-2022-301-2022 is OK
- 10.21105/joss.02305 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[hugoledoux]

@editorialbot add @martibosch as reviewer

[editorialbot]

@martibosch added to the reviewers list!

[lukasbeuster]

Review checklist for @lukasbeuster

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the https://github.com/Sydney-Informatics-Hub/geodata-harvester?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@sebhaan) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• 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, who the target audience is, and its relation to other work?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[hugoledoux]

@sjsrey & @martibosch : could you please do @editorialbot generate my checklist to make sure everything works?

[sjsrey]

@sjsrey & @martibosch : could you please do @editorialbot generate my checklist to make sure everything works?

It isn't clear to me how to proceed from the instructions?

[hugoledoux]

@sjsrey you mean for the JOSS review or for the package you are reviewing?

If for JOSS, you need to generate the list of criteria we use, and then go through the list and check those that the submission fulfils. It's better explained there: #5205 (comment)

If some parts are not fulfilled, then you write it here in this issue and you can provide a solution if you know how. We're here to help the submission be at the "JOSS level", to help the authors.

[hugoledoux]

@lukasbeuster : how is the review going on?

@martibosch : could you please start your review at least generating the checklist so we know it is working? @editorialbot generate my checklist

[martibosch]

Hello @hugoledoux.

I have to finish a project by next monday, I will get to the review on tuesday.

Sorry for my delay.

[martibosch]

Review checklist for @martibosch

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the https://github.com/Sydney-Informatics-Hub/geodata-harvester?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@sebhaan) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• 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, who the target audience is, and its relation to other work?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[hugoledoux]

@sjsrey are you finding your way here? Have you found how it works?

Could you please type this to ensure everything is working fine for you? @editorialbot generate my checklist

[hugoledoux]

@martibosch @lukasbeuster any updates or a timeline for when you think you can work on this submission?

[sjsrey]

Review checklist for @sjsrey

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the https://github.com/Sydney-Informatics-Hub/geodata-harvester?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@sebhaan) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• 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, who the target audience is, and its relation to other work?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[lukasbeuster]

Hi @sebhaan,

sorry for the extensive delay while processing the submission.

Let me first say that I'm excited about the piece of software. I do think it has the potential you subscribe to it to ease access to EO data for researchers and will help people to get up and running with their analyses much faster than usual!

That being said, I do have some feedback after testing around a little:

Installation and first use:

• The documentation should be clearer around the settings.yml file needed to run the first harvest. You could suggest that people clone the repo for their first use so they can execute the example notebooks and try out both widget and manual settings creation with ease.
• You explicitly mention GEE as optional, yet require it to run the example notebooks. This adds an additional layer of complexity that I would suggest you avoid. If you could showcase the GEE initialisation in a separate example that would be better. I ended up removing GEE manually from the respective settings.yml files after failing to initialise (will try again separately).

Harvesting:

I encountered a few hiccups while exploring:

• The example_harvest notebook results in an "UnboundLocalError" on my end, something to do with a local variable in the harvest function:

---------------------------------------------------------------------------
UnboundLocalError                         Traceback (most recent call last)
Cell In[3], line 1
----> 1 df = harvest.run(infname, preview = True, return_df = True)

File /opt/anaconda3/envs/geodata_harvester/lib/python3.11/site-packages/geodata_harvester/harvest.py:272, in run(path_to_config, log_name, preview, return_df)
    270     layer_titles += [layername]
    271     layer_list += [layername]
--> 272     agg_list += ['None']
    273     continue
    275 xdr = temporal.multiband_raster_to_xarray(files_layer)

UnboundLocalError: cannot access local variable 'agg_list' where it is not associated with a value

• harvest preview: The resulting plots appear a bit messy (e.g., overlapping titles/flipped). I'm not sure they currently serve any function other than showing that there are some results because values are not shown. I'd either clean/remove the preview or make the output more useful.
• optional: Some sources take quite some time to download. It would be nice to have a disclaimer when harvesting 'slower' sources to expect a longer download time (i.e. the SILO max/min temperature calls in the example notebooks took > 20 minutes on my end).

Widgets:
I have a few points regarding the widgets. They are a cool feature, but currently not very intuitive.

• It would be nice to have some more explanation within the widget, e.g. to clarify the input needs (csv/yml/?). This should include the bounding box (maybe there is a way to automatically derive the bbox from the input, but that'd be optional in my mind - clear documentation in the widget would be my priority).

• Automatically populates data sources in the settings.yml even if no data is requested (ticked in the corresponding tab). E.g., adds a GEE prompt even if no GEE data is needed resulting in a GEE initialisation. This should be resolved so that the widget populates with selected data sources only.

• Widget creates erroneous settings file: The widget uses the terminology settings.temp_intervals. This results in an error when harvesting:

AttributeError                            Traceback (most recent call last)
Cell In[15], line 1
----> 1 df = harvest.run(fname_settings, return_df = True)

File /opt/anaconda3/envs/geodata_harvester/lib/python3.11/site-packages/geodata_harvester/harvest.py:108, in run(path_to_config, log_name, preview, return_df)
    104 # Temporal range
    105 # convert date strings to datetime objects
    106 date_diff = (datetime.strptime(settings.date_max, "%Y-%m-%d") 
    107     - datetime.strptime(settings.date_min, "%Y-%m-%d")).days
--> 108 if settings.time_intervals is not None:
    109     period_days = date_diff // settings.time_intervals
    110     if period_days == 0:

AttributeError: 'types.SimpleNamespace' object has no attribute 'time_intervals'

The validate_settings function doesn't pick this up. Could it be that the harvest function input was changed from temp_intervals to time_intervals at some point? If you could please investigate and potentially fix the widget output and validate_settings function.

Paper:

• references aren't populating in the paper.md

That's my take for now. Looking forward to hearing your and the other reviewers' responses.

Best
Lukas

[martibosch]

Hello,

sorry for the delay. Here is my review:

The geodata-harvester library intends to provide a common interface to automate the access and preprocessing of a variety of geospatial and environmental data. This is indeed very convenient but I have three main (interrelated) remarks about the library:

• If I understand its prupose correctly, it appears very similar to intake - maybe a bit more tailored to geospatial (and temporal) data. Since it seems that the library tries to standardize geospatial data access, why not using the existing intake approach and write the implemented data sources as intake plugins? There may actually be a good reason not to do so, but in such a case, it would be interesting to explain it (maybe in the statement of need?), e.g., what are the advantages when compared to intake.
• after going through the paper, documentation and notebooks is that the scope is too broad so the provided features feel too abstract to the reader. I think it would help if the README included a simple snippet and pointed to an example notebook with a more specific use-case that provides clearer insights into the main features of the package. Currently, the notebooks barely include the harvest.run method and its resulting logs, but more text should be added so that the reader/potential user understands better what is going on and thus how the package may be useful. After all, mixing markdown and Python code is what makes Jupyter notebooks so powerful. Additionally, I would showing what a config file, e.g., settings_harvest.yaml, looks like within the notebook, e.g., see how %%writefile is used in cell 3 of the intake tutorial. I would first focus on explaining the automatic retrieval and basic spatiotemporal processing features (e.g., bounding box, spatial/temporal resampling...), then move on to describing the automatic generation of data frames and maps for ML (with the current notebooks, I actually do not understand how to use such a feature).
• I have not been able to execute the notebooks since I do not have access to GEE - I requested access some weeks ago but have not heard back from them. Is it possible to use any of the features without a GEE account? If so, would it be possible to add a corresponding example notebook?

Given the current materials (notebooks, documentation...), as an external reader/user with some expertise in the field, I understand the features that you aim to provide but I have a hard time understanding how I may use this library within my work. In my opinion, this can be improved by providing more detailed (and concise) example notebooks. The SIH-AgReFed Workshop materials give a more thorough overview but may be overwhelming for someone who is just checking out the library.

In any case, I am looking forward to this moving forward. I will finish the other points in the checklist on monday. Best,
Martí

[martibosch]

Regarding the checklist:

General checks

• Data sharing and Reproducibility: I think it would be great to have an example notebook that can run without a GEE account. Otherwise, it should be clearly noted that a GEE account is required to use this library. I actually have run the notebook with a GEE account and got the following error on example_harvest.ipynb:

Starting the data harvester -----
ℹ Found the following 7 sources: ['DEA', 'DEM', 'Landscape', 'Radiometric', 'SILO', 'SLGA', 'GEE']

Downloading from API sources -----
⊙ Initialising Earth Engine... 2.9s                                    
✔ Done

⌛ Downloading Google Earth Engine data...
Running preprocess() -----
ℹ Number of image(s) found: 1
⊙ Applying scale, offset and cloud masks... 1.2s                       
⊙ Calculating spectral indices: NDVI... 0.5s                           
✔ Preprocessing complete
Running download() -----
ℹ Band(s) selected: ['NDVI_median']
ℹ Setting scale to ~160.2m, converted from 6.0 arcsec at latitude -30.27
ℹ Setting download dir to results/ee
⚑ ee_LANDSAT_975fd1b8.tif already exists, skipping download
✔ Google Earth Engine download(s) complete
Running preprocess() -----
ℹ Number of image(s) found: 0
✖ Can't process zero images. Processing stopped

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[3], line 1
----> 1 df = harvest.run(infname, preview = True, return_df = True)

File ~/mambaforge/envs/geodata-harvester/lib/python3.10/site-packages/geodata_harvester/harvest.py:201, in run(path_to_config, log_name, preview, return_df)
    199 # run eeharvest
    200 gee_outpath = os.path.join(settings.outpath,'ee')
--> 201 gee = eeharvester.auto(config=tmp_config, outpath=gee_outpath)
    202 if not isinstance(gee.filenames, list):
    203     # convert to list
    204     gee.filenames = [gee.filenames]

File ~/mambaforge/envs/geodata-harvester/lib/python3.10/site-packages/eeharvest/harvester.py:640, in auto(config, outpath)
    637 else:
    638     # download single collection
    639     img = collect(config=config)
--> 640     img.preprocess()
    641     if outpath is None:
    642         img.download()

File ~/mambaforge/envs/geodata-harvester/lib/python3.10/site-packages/eeharvest/harvester.py:269, in collect.preprocess(self, mask_clouds, mask_probability, reduce, spectral, clip, **kwargs)
    267 if count.getInfo() < 1:
    268     msg.err("Can't process zero images. Processing stopped")
--> 269     raise ValueError("No image to process, check your date range")
    271 # Cloud and shadow masking
    272 if mask_clouds:

ValueError: No image to process, check your date range

Functionality

• Functionality: see the point above.

Documentation

• A statement of need: I think it could be improved based on my first point of my review (in my other comment).
• Example usage: see point above about Data sharing and Reproducibility
• Automated tests: while I see tests in the tests folder, I do not see any instructions on how to run them. I believe that the authors should add them in the README or contribution guidelines. Additionally, they should consider automating the test execution with GitHub Actions (or a similar tool) to setup a git-ops CI workflow that requires tests to pass for each push/PR.

Software paper

• A statement of need: same as the point above in the "Documentation" section.
• State of the field: again, in line with the first point of my review (in my other comment), I believe the authors should improve this part by commenting how geodata-harvester compares to other similar tools, e.g., intake.

That is it for my review. Looking forward to the authors responses. Best,
Martí

[martibosch]

A final note which I forgot: when I install geodata-harvester from conda-forge, I get a ModuleNotFoundError, which I do not get when I install it using pip.

[sebhaan]

Hi @martibosch and @lukasbeuster,
Just wanted to drop you both a quick note to say a huge thanks for your feedback on this software. You suggestions and bug reports are super helpful and have given me a roadmap for potential enhancements. I'm gearing up the next development cycle beginning next week and I'll be taking a close look at all of your suggestions, including a detailed response to your comments. I will reach out if I need some clarification on your points.
Thanks again, and I'll keep you posted on the progress.

[sebhaan]

@editorialbot generate pdf

[editorialbot]

👋 @openjournals/ese-eics, this paper is ready to be accepted and published.

Check final proof 👉📄 Download article

If the paper PDF and the deposit XML files look good in openjournals/joss-papers#4564, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept

[kthyng]

Ok final steps:

• Check that version was updated
• Check that software archive exists, has been input to JOSS, and title and author list look good
• Check paper

[kthyng]

@sebhaan
Please check the capitalization in your references. You can preserve capitalization by placing {} around characters/words in your .bib file.

[sebhaan]

@editorialbot generate pdf

[editorialbot]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[sebhaan]

@kthyng
the capitalization in .bib has been corrected. Checked proof.

[kthyng]

@editorialbot accept

[editorialbot]

Doing it live! Attempting automated processing of paper acceptance...

[editorialbot]

Ensure proper citation by uploading a plain text CITATION.cff file to the default branch of your repository.

If using GitHub, a Cite this repository menu will appear in the About section, containing both APA and BibTeX formats. When exported to Zotero using a browser plugin, Zotero will automatically create an entry using the information contained in the .cff file.

You can copy the contents for your CITATION.cff file here:

CITATION.cff

cff-version: "1.2.0"
authors:
- family-names: Haan
  given-names: Sebastian
  orcid: "https://orcid.org/0000-0002-5994-5637"
- family-names: Harianto
  given-names: Januar
  orcid: "https://orcid.org/0000-0002-4803-108X"
- family-names: Butterworth
  given-names: Nathaniel
  orcid: "https://orcid.org/0000-0002-1212-8816"
- family-names: Bishop
  given-names: Thomas
  orcid: "https://orcid.org/0000-0002-6723-7323"
contact:
- family-names: Haan
  given-names: Sebastian
  orcid: "https://orcid.org/0000-0002-5994-5637"
doi: 10.5281/zenodo.8339817
message: If you use this software, please cite our article in the
  Journal of Open Source Software.
preferred-citation:
  authors:
  - family-names: Haan
    given-names: Sebastian
    orcid: "https://orcid.org/0000-0002-5994-5637"
  - family-names: Harianto
    given-names: Januar
    orcid: "https://orcid.org/0000-0002-4803-108X"
  - family-names: Butterworth
    given-names: Nathaniel
    orcid: "https://orcid.org/0000-0002-1212-8816"
  - family-names: Bishop
    given-names: Thomas
    orcid: "https://orcid.org/0000-0002-6723-7323"
  date-published: 2023-09-15
  doi: 10.21105/joss.05205
  issn: 2475-9066
  issue: 89
  journal: Journal of Open Source Software
  publisher:
    name: Open Journals
  start: 5205
  title: "Geodata-Harvester: A Python package to jumpstart geospatial
    data extraction and analysis"
  type: article
  url: "https://joss.theoj.org/papers/10.21105/joss.05205"
  volume: 8
title: "Geodata-Harvester: A Python package to jumpstart geospatial data
  extraction and analysis"

If the repository is not hosted on GitHub, a .cff file can still be uploaded to set your preferred citation. Users will be able to manually copy and paste the citation.

Find more information on .cff files here and here.

[editorialbot]

🐘🐘🐘 👉 Toot for this paper 👈 🐘🐘🐘

[editorialbot]

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

0. Check final PDF and Crossref metadata that was deposited 👉 Creating pull request for 10.21105.joss.05205 joss-papers#4577
1. Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.05205
2. If everything looks good, then close this review issue.
3. Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? Notify your editorial technical team...

[kthyng]

Congrats on your new publication @sebhaan! Many thanks to editor @hugoledoux and reviewers @lukasbeuster and @martibosch for your time, hard work, and expertise!!

[editorialbot]

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.05205/status.svg)](https://doi.org/10.21105/joss.05205)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.05205">
  <img src="https://joss.theoj.org/papers/10.21105/joss.05205/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.05205/status.svg
   :target: https://doi.org/10.21105/joss.05205

This is how it will look in your documentation:

We need your help!

The Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: https://reviewers.joss.theoj.org/join
• Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss