duplicated StemTag issue

[ValentineHerr]

There are a number of (new?) stems that don't have a stemtag entered. And tag 10826 stemtag 2 has 3 different entries.

Hopefully you all are aware of this. I see in the comments that you have entered a tag number, so I am guessing the app was glitching for new stem tags?

Please see the error report if needed.

[CarolineTroy]

Hi Valentine - yes, the app currently won't let us edit the stem tag number when we add new stems. The field is automatically blank and uneditable. We are putting the stem tag number in the comments currently, but it is something we will need to resolve in the app. I'm not sure about the case for tag 10826 specifically, but we were occasionally also experiencing a glitch where when adding new stems to a new recruit, the stems weren't added to the recruit we were editing, but a separate recruit we had created earlier. In those cases we put the info for the new stems in the comments instead. Maybe that is why for 10826 there are 3 stem 2's.

[ValentineHerr]

ok sounds good

[ValentineHerr]

(@jess-shue, I am bringing the duplicated stemtag conversion in the corresponding issue.)

FYI, there are still 19 duplicated tag-stemtag duplicates, in 3 different quadrats. No indication of what the stemtag should be in the notes.

@jess-shue said that she is working on it.

[jess-shue]

@ValentineHerr I've now added the correct StemTag number to those stems without a number.

I'm hesitant to change the duplicate numbers because of the colored wire. @mitreds, @rmh24, @CarolineTroy, @Iriskennedy, @krystalbagnaschi: Any sense of stems of 10878, 10819, 10840, and 10826? You haven't been using tags but just wire, correct? I don't want to assign new numbers that wouldn't correspond to the wire color. Once you have tags, you can hopefully edit those stems in the app.

[ValentineHerr]

@jess-shue, Thanks for having delt with the problematic stems above.

However, now that I am bringing in recruit data, there is a systematic issue: the recruits stem table has the same data as the old_tree stem table (except the old stem has one extra column, dbh_2018_mm, but if I remove it, they are really identical, see code snippet below). The tree tables are fine (old_tree one has a ton of rows, and recruits one only has a few hundreds).

Is this intended behavior? Shouldn't the recruits stem table only have the secondary stems associated with the recruits tree table? Can you address that or should I find a way to address it in my code?

> old_stem <-  fread("raw_data/old_trees/stem_table_1.csv")
> recruits_stem <- fread("raw_data/recruits/stem_table_1.csv")
> old_stem$dbh_2018_mm <- NULL
> identical(recruits_stem, old_stem)
[1] TRUE

Note that once this is resolved, there will still be 26 duplicated stemtag issues to address.

[jess-shue]

@ValentineHerr This is an artifact of how the 'view' is made - basically it is a copy of the tree and stem table. I did not include a column for stems that is in the tree table - thinking it would eliminate them as they are associated with the tree table but it did not. I don't believe there is a good solution for this through ArcGIS Online - but let me look into it. I'm hesitant to do too much and mess things up!

[ValentineHerr]

ok, keep me posted. And if it is too much to deal with it, just let me know and I'll come up with a plan on my end.

[ValentineHerr]

Most of the duplicated tag issues were caused by the fact that the recruit stem table has the old tree stem table data in it. I fixed that in the script.

So now, all the duplicated tags issues are legitimate and need to be addressed. @CarolineTroy @Iriskennedy @rmh24 @krystalbagnaschi let me know if we need to meet again about that and/or other data errors, or if you can address that alone.

[jess-shue]

@ValentineHerr Thank you for scripting this, I didn't have a chance to work on it prior to my trip!