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

FHX file error checking #77

Open
chguiterman opened this issue Mar 2, 2017 · 7 comments
Open

FHX file error checking #77

chguiterman opened this issue Mar 2, 2017 · 7 comments
Labels
enhancement New feature or request

Comments

@chguiterman
Copy link
Contributor

We need to ID data format problems in read_fhx. For example, if a series has a fire scar prior to the innermost ring in the series, this impossibility is currently ignored with no warning.

Ideally, we would provide a means to fix the problem in the burnr library

@brews
Copy link
Member

brews commented Mar 3, 2017

Hey @chguiterman ,

Could you provide an FHX file giving an example of 1) what burnr does right now, 2) what you want burnr to do?

@brews brews added bug Something isn't working enhancement New feature or request labels Mar 3, 2017
@brews brews closed this as completed Mar 3, 2017
@brews brews reopened this Mar 3, 2017
@chguiterman
Copy link
Contributor Author

chguiterman commented Mar 3, 2017

Relevant FHX file,
Dumb_broke_fhx.txt

Burnr ignores the problems right now, plotting exactly what it finds.
It should (at least) warn the user that a physical impossibility exists.
For example:

read_fhx("dumb_broke.fhx")
There are 2 warnings, see warnings() to view [or whatever the default output is]
warnings()
series ABC-01 includes an event _before_early-most ring
series ABC-06 includes an event _after_outer-most ring

@brews
Copy link
Member

brews commented Mar 3, 2017

I see!

Okay, so thinking about rules, we should check that:

  • nothing before inner or pith event

  • nothing after outer or bark event

And throw a full stop (not warning) if these rules are broken...? Sound good?

@chguiterman
Copy link
Contributor Author

Your rules are good.

A stop could jam looping through opening lots of files. A detailed message (with object/file name and series) might be better. The series could be cut at pith/bark or inner/outer rings and those out-of-bounds events would be omitted. This is maybe better than forcing a user of another's file to change their dating without knowledge of the actual error or means to fix it appropriately.

@brews brews self-assigned this Mar 6, 2017
@brews brews added this to the v0.2.0 milestone Mar 6, 2017
@brews brews removed the bug Something isn't working label Mar 8, 2017
@brews
Copy link
Member

brews commented Mar 8, 2017

Okay. I think we can write I function to check for this kind of thing, stick it at the end of the fhx() constructor and have it check things anytime an fhx object is instantiated.

@chguiterman
Copy link
Contributor Author

chguiterman commented Mar 8, 2017 via email

@brews brews modified the milestone: v0.2.0 Aug 17, 2017
@brews brews removed their assignment Jan 15, 2021
@chguiterman
Copy link
Contributor Author

chguiterman commented Mar 30, 2021

This is still an area of interest. Just ran into another problem that {burnr} should flag: no outer-year code
EDIT 2022-11-29: There's no need to flag series that end on scar/injury features. These are not unusual in the real world because samples often degrade outside the scarring sequence (ie they break on the scar and you lose the outer or inner rings). {burnr} capably handles these cases and it does not affect summary stats or other stats, like composites or intervals. FHAES even allows it

chguiterman added a commit to chguiterman/burnr that referenced this issue Nov 29, 2022
chguiterman added a commit to chguiterman/burnr that referenced this issue Nov 29, 2022
…s as flagged by check_series() and other functions. Somewhat addresses ltrr-arizona-edu#77
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants