crghilardi / forestbiometrics.jl Goto Github PK

Pertinent info in pull request #13. Move to use recipes to reduce dependencies and hopefully make life easier

I managed to have the package build succesfully on the stable 64 bit Julia release on Appveyor. It still fails on both 32 and 64 bit nightlies and 32 bit stable. I am not sure how to fix this, but this may be pertinent to the discussion?

This is more of a long-term goal, but the ability to define logic for metric and imperial calculations is a huge opportunity and I think would be massively popular. Currently, most models I see are written in one or the other with no "easy" way to switch or select. See this ticket for the FVS example where they have to chose when and where to convert and other difficult decisions.

The tag name "0.1.1.2" is not of the appropriate SemVer form (vX.Y.Z).
cc: @Crghilardi

The tag name "0.1.3" is not of the appropriate SemVer form (vX.Y.Z).
cc: @Crghilardi

I tried this briefly but got all sorts of errors due to Nullable arrays. Putting off until later

• add codecov to travis and coverage badges
• decide on if tests against nightlies and other non stable releases are wanted/needed

See: https://www.growthmodel.org/papers/ORGANON_MATRIX.PDF

Implementing this would be useful, and I think it would blend well if we had a type for common growth model outputs so that it could be made into a recipe(?). Something like ::FVS_Summary

I am not sure how to do this with Github, I will try to start at a 0.1.0.

There have been some syntax changes (re: gingrich_chart and HeightDub) that have yet to be updated in the docs or the example notebooks.

I would also like to see if we can figure out how to build the notebooks on deploy, rather than have static ones.

SDI_graph and GingrichStocking_graph need to be re done and put into a function form. The existing code is something I created around Julia 0.3 for playing around with, so they are clunky and slow.

Edit: I have since moved the charting functions from Gadfly to Plots.jl. I have been having problems with Gadfly for a while and it seems like Plots is the focus of much more energy than Gadfly.

To do:

• wrap plotting into actual functions
• Plot recipes?
• fix axis label formatting issue on SDI chart
• streamline behind the scenes calculations for the actual lines

While I have something (sort of?) working for @HeightDub, I don't think I am doing exactly what I want to be doing. As a result I wanted to write up a short little explanation for what I am trying to accomplish for anyone else who looks at this project.

Height-diameter equations are simple to compute once you decide on a equation form and have your fitted parameters ready. The problem arises where height diameter equations cover decades of research and have proliferated to account for such a wide array of factors such as species, regional differences, etc.

Typically, growth and yield models will have some height-diameter logic built in but it will be hardcoded based on who wrote in and what region they are working in with no options to change model form or parameters.

My goal for the @HeightDub macro was to create logic such that the equation form and parameters are modular and can be switched out as needed for a wide array of routinely used forms and/or parameter sets (FVS variants for instance) or the user can designate a whole new form/parameter set if pre-allocated ones do not fit the need.

Currently, I use a dictionary to hold the species level coeffecients in the form of String: Array{Float64}, and I use anonymous functions in the form of (x,b)->x+b[1]^2n where x is the dimater of the tree record and b is an array of an arbitrary number of coeffcients to account for 2 vs 3 vs n parameter forms of the equations.

I started thinking about this a while ago and even inquired on SO as to how I should approach this. I am not devoted to the idea of a macro, but it was the only way I could produce the desired behavior.

Currently all formula and functionality add 4.5 to account for diameter at breast height. In the future, I hope to add the ability to take heights from any arbitrary point.

I am not sure what this would look like if it would be better to add a parameter to the HeightDiameter type, or some kind of macro on the backend to modify the formula lambdas