Coder Social home page Coder Social logo

sdmdl's Introduction

Build Status License: MIT Coverage Status Documentation Status Updates

sdmdl

An object-oriented python package for species distribution modelling using deep learning. The package allows for a more intuitive and easy exploration of biodiversity patterns by modelling preferences for a great number of environmental variables.

Instructions for installing and using the sdmdl package can be found here.

Case study

The functionality of this package and the estimates of environmental preferences it obtains is demonstrated by way of a use case on domesticated crops and their wild progenitors.

The raw uninterpreted results of this case study can be found here.

Acknowledgments

Package layout

  • CONTRIBUTING.md - hints for how to contribute to this project
  • LICENSE - the MIT license, which applies to this package
  • README.md - the README file, which you are now reading
  • requirements.txt - prerequisites to install this package, used by pip
  • setup.py - installer script
  • data/ - contains some files that are (currently) required for data preprocessing - marked for deletion
  • docs/ - contains documentation on package installation and usage
  • sdmdl/ - the library code itself
  • tests/ - unit tests

sdmdl's People

Contributors

pyup-bot avatar rvosa avatar winandh avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

sdmdl's Issues

Werkoverleg 2019-08-27

  • project doelstellingen:
    • publiceerbare, herbruikbare Python toolkit voor SDM-DL (app. note; pyPI package)
    • toepassing van toolkit op use cases (2+ research papers)
    • formuleren van vervolg(-aanvraag)
  • use cases:
    • HS voor Observation.org data om beeldherkenning mee te schalen.
    • idem voor planten met/zonder secundaire houtigheid
    • idem voor planten met ectomycorrhiza, arbusculaire mycorrhiza, of iets anders
    • idem voor gedomesticeerde versus wilde planten
  • toolkit:
    • consumeren van occurrences van diverse bronnen (GBIF/Observation.org/derden). In scope: transformeren van data in diverse formats (e.g. TSV/CSV/DarwinCore/JSON). Out of scope: opschonen van data, wat b.v. kan met CoordinateCleaner etc.
    • consumeren van GIS data van diverse bronnen (bioclim/envirem/derden/map queries). In scope: importeren van diverse formats (e.g. TIFF/BIL); croppen; herprojecteren; bufferen. Out of scope: complexere GIS operaties.
    • consumeren van andere variabelen (metadata van waarnemingen)
    • configureren/runnen/evalueren van model training. In scope: prepareren van input vectors (e.g. co-occurrences ja/nee); configureren/parameteriseren van DNN topologie; epochs. Evaluatie van AUC's en variable contributions.
    • projecteren van modelvoorspellingen. In scope: genereren van habitat suitability (HS) kaarten/data sets voor huidige verspreiding. Out of scope: IPCC klimaatvoorspellingen.
  • vervolgmogelijkheden:
    • NLeSC resultaten, toekomstige mogelijkheden
    • ALW/Klein
    • JADS
  • resources:
    • werkplekken
    • opslag van occurrences en GIS data (lokaal)
    • managen van literatuur / references
    • GPU (Wilfred vragen)

SHAP version 0.30.0 value error

When running SDMDL, there is a very small chance of running into the following error:

ValueError: minvalue must be less than or equal to maxvalue 
in: color.py, cm.py, collections.py, artist.py

This error occurs in sdmdl/trainer.py, on lines 235-239 and/or 242-246 when figures are created in the validate_model function.

This traces back to SHAP being unable to create a figure using matplotlib, as features contribute to the model outcome equally.
This is fixed in SHAP version 0.34 and onwards, however, updating to this version would break the SDMDL package even further.

Code review

Code review


  • Probleem: hard coderen van paden op veel locaties

Op heel veel plekken los van elkaar worden dezelfde paden hard gecodeerd in de code.
(Voorbeeld: /data/GIS/layers/... komt heel vaak terug in de code). Dat is een probleem
omdat we hierdoor vanaf nu getrouwd zijn met bepaalde locaties die vrijwel niet meer te
wijzigen zijn. Bovendien is de code niet consequent: de ene keer is het gis, de andere
keer GIS. Dat werkt op OSX en Windows maar niet op Linux (want dat is case sensitive).

Niet alleen is dat een probleem voor onszelf, maar nog veel erger voor eventuele
gebruikers (=Wouter), die hun TIF layers op exact de juiste (niet-gedocumenteerde) plek,
met de juiste naam, in een specifieke nesting moeten zetten. Dat gaat ze nooit lukken.

Hard gecodeerde paden en duplicatie zijn een symptoom van een fragiel, moeilijk te
onderhouden ontwerp: http://wiki.c2.com/?OnceAndOnlyOnce

Een iets betere optie zou zijn dat zo'n pad maximaal op een plek staat, namelijk
binnen de code van een configuratie-object (of andere abstractie) die paden beheert. De
kennis over de paden is dan geconcentreerd op een plek en hoeft dus alleen daar aangepast
te worden. Nog beter is als die kennis op nul plekken in de code staat, en volledig
afhankelijk is van een configuratiebestand.

Hier zijn voorbeelden van het probleem:
https://github.com/naturalis/sdmdl/search?l=Python&q=%27%2Fdata%2FGIS%2F%27
https://github.com/naturalis/sdmdl/blob/master/script/python/train.py#L3

Gerelateerd hier aan is ook het probleem dat hard gecodeerd getest wordt op .tif,
terwijl de bestands-extensie in werkelijkheid niet case sensitive hoeft te zijn (dus
.TIF is ook een valide naam), en zelfs ook iets anders zou kunnen zijn (nl. .tiff of
.TIFF).

Oplossing: paden laten beheren via een configuratie abstractie


  • Probleem: te lange methods

Elke method (of functie) moet ongeveer een scherm vol zijn: ±40 regels. Als dat onmogelijk
lijkt dan probeert de method dus te veel te doen en moet opgesplitst worden:
http://wiki.c2.com/?LongMethodSmell

Oplossing: methods opsplitsen


  • Probleem: hard gecodeerde dictionary keys

Op een aantal plekken in de code zijn kolomnamen van de DarwinCore archives hard
gecodeerd, en laten dan een mix zien van CamelCase en underscore_case. Dit is een
probleem omdat we hierdoor getrouwd zijn met hele specifieke (en custom) structuren
voor onze data. Als Wouter met de data van observation.org aan de slag wil dan heeft
hij vast andere namen voor de kolommen. Wat er moet gebeuren is dat er een Occurrence
class is (of iets dergelijks) die dit intern beheert zodat de rest van de code de
specifieke details van de databestanden niet hoeft te weten. Als dan blijkt dat het in
observation.org decimal_latitude in plaats van decimalLatitude us dan hoeft er maar op
een plek iets aangepast te worden. Bijkomend voordeel is dat je zo ook geen typefouten
in de code kan krijgen (bijvoorbeeld, per ongeluk data["decima1Latitude"]).

Oplossing: een aparte class voor DarwinCore records, idealiter als subclass van een
al bestande DarwinCore library


  • Probleem: niet (goed) testbare code

Een verzameling losse scripts is niet hetzelfde als een hebruikbare, testbare API. Het
moet mogelijk zijn om elk stukje van de code via een unit test te verifieren. Dat kan
eigenlijk alleen maar (of althans, op een veel meer voor de hand liggende manier) als
de code bestaat uit classes die door de unit test suite geimporteerd kunnen worden om
zo de functionaliteit van elke method te testen. Het doel is dat de coverage om en
nabij de 100% wordt.

Oplossing: toch echt wel een daadwerkelijke OO API. Het doel is om dus van de
huidige 0% coverage (https://coveralls.io/github/naturalis/trait-geo-diverse-angiosperms?branch=master)
tot een ruim voldoende/goed te komen


  • Probleem: geen goede documentatie van de methods

Het moet zo zijn dat we uiteindelijk automatisch goede documentatie kunnen genereren
(bijvoorbeeld op readthedocs). Dat gaan we doen door een combinatie van goede docstrings
in de code en goede [.rst](https://en.wikipedia.org/wiki/ReStructuredText) documentatie,
te beginnen bij /docs/index.rst

Voorbeeld van goed gedocumenteerde code:
https://github.com/BelgianBiodiversityPlatform/python-dwca-reader/blob/master/dwca/read.py

Automatisch gegenereerde documentatie:
https://python-dwca-reader.readthedocs.io/en/latest/api.html

Oplossing: code zodanig documenteren dat het readthedocs knopje op groen komt te
staan: https://readthedocs.org/projects/sdmdl/


  • Probleem: hard gecodeerde 'magic numbers'

Voorbeelden:

  • random number seed ("42")
  • aantal pseudo absences ("2000")
  • parameters voor plots (palet e.d.)

Oplossing: moeten allemaal via de configuratie beheerd worden (met defaults)


  • Probleem: print() statements voor debugging

Voorbeelden: https://github.com/naturalis/sdmdl/search?q=print&unscoped_q=print

Oplossing: vervangen door logging

Suggesties voor de API

Aan de collecties van scripts kan je in grote lijnen zien hoe de API er uit zou moeten
zien. De namen die ik hier hanteer dienen even als voorbeeldjes:

  • config - een class die de configuratiebestanden (e.g. YAML) inleest en de waardes
    via methods beschikbaar maakt aan de rest. Is verantwoordelijk voor het aanleveren
    van defaults (dus niet via magic numbers elders in de code), het construeren van
    locaties van invoer- en uitvoerbestanden.
  • model_trainer - een class die de training van het model aanstuurt, d.w.z. de
    input parameters vanuit de configuratie ophaalt en overdraagt aan keras, vervolgens
    de voortgang / het succes van de training evalueert, en het model kan opslaan
  • model_predictor - gegeven een getraind model (eventueel in te lezen van een bestand)
    zorgt deze class dat er voorspellingen gedaan worden
  • gis_handler - weet alles van het inlezen, croppen, rescalen, plotten, wegschrijven
    van GIS data
  • occurrence_handler - weet alles van het inlezen, filteren, converteren, wegschrijven
    van DarwinCore (-achtige) data

Publication goals

  • Good code documentation - meaning both documentation at the level of methods (in progress, getting there) and at the user level, i.e. a Usage example with a simple, working, analysis run through in /docs/index.rst
  • paper.md / paper.bib - the idea is that the Usage example is written up in such a way that it integrates automatically in a paper.md that can be submitted to JOSS. For example, with some basic grep/redirect logic so that the correct section(s) in index.rst end(s) up in the markdown. rst -> markdown via pandoc
  • Submissions - the repository is now activated on Zenodo.org, such that when we prepare a release, it will be tagged with a DOI, at which point we will insert it as a badge on the homepage README.md. We will then submit to JOSS, deal with the reviews, and add their badge upon acceptance.

Code reorganization

  • Alle R code moet naar de data repo.
  • De Python scripts moeten uitgekleed worden zodanig dat alle functionaliteit in OO classes komt te staan. Eventuele scripts die dan nog nodig (of nuttig) zijn bevatten dan bijna geen code maar zijn puur wrappers rond de OO classes.
  • Er is nu een soort duplicatie van zowel een scripts folder als de sdmdl folder met schijnbaar dezelfde code. Scripts folder opschonen.

Data reorganization

The data folder needs to go. Roughly the following needs to happen:

  • GIS data are 3rd party assets. They go in some ephemeral, local folder that we don't advertise to the outside world.
  • Occurrence data go in a shared folder structure where we can access them internally, e.g. a dropbox or google drive. We embargo them for now.
  • Species lists, traits, are in https://github.com/rvosa/sdmdl-angiosperm-data
  • To the extent that this folder is now a template (or example) for users to run their
    analyses in, this folder can perhaps live on inside 'docs'.

Initial Update

The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.