new records not included in ForC_simplified because of "NA" status in conflicts

[teixeirak]

@ValentineHerr , I just noticed that some of the new data @mawilliams99 and I have been entering has not made it through to ForC_simplified because we don't have anything in the (script-filled) field conflicts.

For some, this is easily solved because the data are independent and could manually be flagged as such. However, there are some new duplicates (mainly newer estimates for ForestGEO plots).

What do you advise?

[teixeirak]

Which fields does the code that creates ForC draw upon? The easiest solution may be to fill in manually, at least temporarily between runs of the duplicate identification code.

[ValentineHerr]

I can try to rerun the duplicate conflict code and hopefully it will fill most of what you entered with "I".

[ValentineHerr]

this may take a little bit of time, there are quite a few scripts I need to go through to make sure we are up to date, and there are things to fix manually, (like missing Koeppen that you need to be fill by hand, probably because coordinates are falling in water or something...)

[teixeirak]

oh, its because we have some missing coordinates.

Also, you mentioned the data set was getting too big for the code. I wonder if it would help to break up by continent?

[ValentineHerr]

that is a great idea!

[teixeirak]

oh, its because we have some missing coordinates.

I'm working on looking these up.

[ValentineHerr]

ok let me know when you are done

[ValentineHerr]

I think coordinates of site ID 3221 (Keller_1986_eonc site at BDFFP) are wrong. Probably latitude is -59.88472 instead of 59.88472

[ValentineHerr]

I'll make the change

[teixeirak]

I just fixed it, and also noticed another that was wrong.

[ValentineHerr]

oh okay, perfect, thanks!

[ValentineHerr]

looks like these guys have wrong coordinates too:

[teixeirak]

I'll fix them now.

[teixeirak]

I just pushed a fixed file

[ValentineHerr]

@teixeirak, I am now looking at conflicts that have changed and need to be reviewed. Here is the first one (and I suspect a lot will follow the same pattern so I want to make sure I get it right now):

If accept the change, it will say that Camille's measurement (3rd row, 1994-1997) has precedence over Tori's (1st row, 1994-1997). Second row (measurement 1997-1998 stays independant)

[teixeirak]

Yes, we'll give precedence to Camille's calculations.

[ValentineHerr]

I don't know how this one will play out (can't remember if we keep S or s), but does this look like the right conflicts?

(the 0 D.precedence on 3rd row is weird... it must be a coming from old conflict, not ideal, it may or may not create an error later, we will see...)

[ValentineHerr]

Piponiot's doesn't get precedence over Lutz at SERC but it does at Wabikon. I think it is because at SERC the date is a range 2009-2011 in Lutz (vs single date 2010 for Piponiot) while at Wabikon they both have the same date (2013).

Same situation with Chave at Mudumalai (Chave has range so it gets precedence over Piponiot)

[ValentineHerr]

Wirth_1999_abas usually gets precedence over Wirth_2002_fast. I believe because Wirth_1999_abas has n = 20 while Wirth_2002_fast has n = 1.
Are we happy with that?

[teixeirak]

Wirth_1999_abas usually gets precedence over Wirth_2002_fast. I believe because Wirth_1999_abas has n = 20 while Wirth_2002_fast has n = 1.
Are we happy with that?

yes

[teixeirak]

Piponiot's doesn't get precedence over Lutz at SERC but it does at Wabikon. I think it is because at SERC the date is a range 2009-2011 in Lutz (vs single date 2010 for Piponiot) while at Wabikon they both have the same date (2013).

Same situation with Chave at Mudumalai (Chave has range so it gets precedence over Piponiot)

Let's edit Piponiot to have the same date range.

[teixeirak]

I don't know how this one will play out (can't remember if we keep S or s), but does this look like the right conflicts?

(the 0 D.precedence on 3rd row is weird... it must be a coming from old conflict, not ideal, it may or may not create an error later, we will see...)

wow, that's complicated... can we manually assign precedence to Piponiot?