Improvements in the data backend (if possible)

[ValentineHerr]

@jess-shue,
As I am looking at the newly downloaded data (for old trees, since recruits need to be resolved) I am noticing a few things that would be good to address to simplify things:

• dbh_mm_2023 does not get populated (which makes sense since data is already recorded in mm) --> get rid of it to avoid confusion (not a big deal if not)
• Columns CreationDate, Creator, EditDate, Editor don't exist anymore. Is that on purpose? I think it would be good to keep which ever refer to when the data was recorded and by whom, in case we have conflicting issues in the future. Maybe it was supposed to be replaced by date_measured but that is empty.
• DBH check and crown_check, These are not the columns I need to look at to not flag issues, are they? I don't think they are, but I don't see the code for "Diameter verified" in the code choices - Oh wait... I see it in the sperate file that you uploaded, but it is not in the data dictionary. I'll consolidate that. So no worries about this (Note: it is always better to be consistent with naming fields: uppercase vs lower case, underscore vs space... e.g: DBH check and crown_check are not consistent, neither are dbh_2018_mm and dbh_mm_2023. (Note: the download has the "Alias" columns of the data dictionary).

[jess-shue]

@jess-shue, As I am looking at the newly downloaded data (for old trees, since recruits need to be resolved) I am noticing a few things that would be good to address to simplify things:

• dbh_mm_2023 does not get populated (which makes sense since data is already recorded in mm) --> get rid of it to avoid confusion (not a big deal if not)
  This field has been deleted, so the only reason I can think of for it coming through was that data was collected in the older version - before that edit was made. Future downloads may exclude it, but I'm not sure.
• Columns CreationDate, Creator, EditDate, Editor don't exist anymore. Is that on purpose? I think it would be good to keep which ever refer to when the data was recorded and by whom, in case we have conflicting issues in the future. Maybe it was supposed to be replaced by date_measured but that is empty.
  The CreationDate and Creator will always be the last update to the data by myself (or whomever is making the layers for the map.) The EditDate would reflect the last edited date in the field, but Editor would again be me as the iPads are currently signed into the app using my credentials - unless they switch to signing in using David's, yours, or Krista's. The date_measured field should not be blank - once they record the personnel that field populates the date and time (although, it looks like the time may be off...). So, the date_measured field should only be blank for trees not yet measured - the entire dataset is being downloaded so for now most will be blank. I believe I can add those fields back in if desired, but most are not helpful as described above.
• DBH check and crown_check, These are not the columns I need to look at to not flag issues, are they? I don't think they are, but I don't see the code for "Diameter verified" in the code choices - Oh wait... I see it in the sperate file that you uploaded, but it is not in the data dictionary. I'll consolidate that. So no worries about this (Note: it is always better to be consistent with naming fields: uppercase vs lower case, underscore vs space... e.g: DBH check and crown_check are not consistent, neither are dbh_2018_mm and dbh_mm_2023. (Note: the download has the "Alias" columns of the data dictionary).
  DBH check and crown_check and calculation fields with rules written in the background to display a warning message to the crew; I'm not sure that anything will be recorded there unless they leave a value unchecked. The name discrepancy is frustrating - there is a 'name' and a field 'alias'. The DBH check is the alias; the field name is not capitalized and contains an underscore - it looks like it is not being consistent with exporting the field name vs. the alias; my understanding had been that the field name would export while the alias would display (for easier reading). My fault, I misunderstood Esri's application of these items.

There have been a lot changes and updates and learning going on, so I apologize for the inconsistencies, but this has been a difficult process. Hopefully, in the future I can correct these problems.

[ValentineHerr]

date_measured is blank for trees that were measured. And I also don't see a column for personnel, is that normal?)

(no worries about Alias, I understand that must be frustrating!)

[ValentineHerr]

@jess-shue,

It would be great if you could:

• delete date_approved from the TREE table (it is all blank since only date_measured gets populated)
• delete date_measured from STEM table (it is all blank, which causes issues when I want to merge date_measured from the tree level info).

Let me know if that is not possible.

[jess-shue]

@ValentineHerr both fields deleted

[ValentineHerr]

I think we can close this