lucy-schick
commented
4 months ago fpr_photo_qa_df is not catching this duplicate because it looks like fpr_photo_qa is not returning a list when it should be since there are 2 inlet photos (see screenshot).
I think this is happening because this line in fpr_photo_qa
stringr::str_subset(., '_barrel\\.|_outlet\\.|_upstream\\.|_downstream\\.|_road\\.|_inlet\\.') %>%is only returning photos that contain the _reserved name ending with a . (example _intlet.) and since the copy photo is_inlet copy it doesn't grab it and therefore won't return a list.
Just tried removing \\. so that it returns photos with any ending and it does include the copy photo but got some other errors. Let me know if you want me to dig into this a bit more.
stringr::str_subset(., '_barrel |_outlet |_upstream |_downstream |_road |_inlet') %>%Removed the copy photo from the directory to fix for the time being.
seeing this on mergin and wondering if it is going to surface as an issue later.
lets have a look at the
scripts/*_photo.Rscripts and reproduce thefpr_photo_qa_dfobject and inspect to see if that catches it. Will be good to know. Be a bit careful to try not to run the scripts that move and resize and rename the photos. Just the qa stuff.Usually we do not want there to be 1. spaces in file names ( i know you know). 2. duplicates of
reservednames for PSCIS required photos (ex.*_inlet.JPGand*inlet2.JPGare fine to submit but*inlet.JPGand*inlet copy.JPGmay not be. Not sure how perfectfpr_photo_qa_dfyet either. haAll FYI here but - The excel submission spreadsheet validation system (see PSCIS user guide methods) might catch it but it is common for it to miss things like that and then the actual PSCIS FTP upload system runs sanity checks in 14th century street latin so is commonly impossible to understand.