Issues/Questions from the MIP Studies Workflow Open Conference Call on July 17, 2008 Issue/Question A user uploaded through Citrix and saw the In-Progress status on the MIP Workflow task. Upon not receiving an automated link for multiple days (3-4 days), the user logs back into Workflow to see that the submissions status has mysteriously reverted to Data Revised although no data had been changed. Answer In general, the MIP will revert to Data Revised if any of the files in the submission folder on the J drive have been changed. The MIP team is aware of a glitch in the system that intermittently may automatically change the name of a metadata file, which reverts the submission back to Data Revised. The development team is currently working to resolve this issue to prevent the status changing to Data Revised when a user has not changed anything in the submission folder on J. Also, contact your RMC Black Belt if you have not received a status change on the MIP Workflow in two business days (for an auto review). Issue/Question We have recently encountered multiple instances where we had to make minor grammatical changes to a Flood Insurance Study (FIS) report or Technical Support Data Notebook (TSDN). This changing of the report requires us to resubmit data to FAFS because Workflow recognized that some files were changed. This appears to be an extra and possibly time-consuming step that is not required, since no files checked by FAFS have been changed. Answer There is a process for uploading these files, without having to go through the Workflow, and therefore without having to resubmit to FAFS. Log in to the MIP, click Tools & Links and click the Data Upload tab. Both the Preliminary FIS and TSDN can be uploaded using this tool. The data will be loaded on to the K drive and automatically moved over to Content Manager where it is stored. Issue/Question Some staff tried that, and noted it put in K drive but in prelim FIS folder. Is that standard? It did not update in the current location on the K drive. Answer For uploads through Tools & Links the submissions are placed in different folders than those submitted through the MIP workflow. TSDN goes into TSDN folder and Prelim FIS to that specific folder. It is okay to not include FIS and TSDN in workflow submission and only submit through Tools & Links. If you do submit both ways, when searching, choose the most recent submission or contact MIP Help to remove the duplicate document(s). Issue/Question Recently, we have noted that random workflow tasks, once assigned to a specific user, will not appear on the Workflow dashboard. Workflow sends the standard emails out that the task has been completed or has been assigned to said user. Review of the Process Admin tab shows the task as being claimed under the user's name. Answer This is a randomly-occurring issue the development team is currently working to determine a fix. For the short term, the development team will run a report daily and fix any problems. Because it is a random occurrence, users can also transfer the task to another user, and then transfer it back to the intended user as an additional short-term workaround. Issue/Question We had made 2 submissions to FAFS for validation using Workflow. After waiting 4+ days, we contacted MIPHelp regarding the delay. They noted that neither of these appeared to be in or even existed in the FAFS queue. This was not the first time submissions to FAFS have been "lost". Answer There are a few low-frequency possibilities as to why the submission appears to be lost between the MIP and FAFS. Each issue must be analyzed individually to determine the cause for the “lost” submission. Please contact your RMC Black Belt no more than 2 business days after you submit for auto to track down the submission. Issue/Question We note that it typically takes FAFS and MIPHelp around 1 day to complete a review and update Workflow. However, we noted on July 1st, it was taking about 2 hours to complete a review and update Workflow. What accounts for the differences in processing speeds? Answer There is only one pipeline between the MIP and the FAFS QA/QC Pro tool. The amount of time it takes to receive a response from FAFS can depend on how many submissions are ahead of you in the queue, how large those submissions are and whether FAFS has to manually intervene to intercept submissions that have been submitted multiple times. The goal is to return the results efficiently, but if you have not received a response in the MIP within 2 business days, contact your RMC Black Belt who can work with MIP Help to track down your submittal. Issue/Question We submitted to the practice review a zip file including images and databases. We recently received word that FAFS received no images. I am ready for a visual review long before the workbench task is available to me, particularly for counties in appeals. Is there a way to submit for practice for databases and visuals before the task appears on the workbench? Answer FAFS is not currently funded to perform practice visual reviews – only practice auto reviews. Previously, FAFS likely processed the practice review you sent through eFTP as an official review as they had no means to determine if it was practice or official. With the new guidance to not send submissions directly to FAFS, the user will have to wait until the correct point in the Workflow to submit for review. If the issue of concern is not having the task available on the Work Items list in a timely manner, an open line of communication between the mapping partner and the RMC to determine what task and/or user may be holding up the workflow may help address this issue. Issue/Question I am having difficulty with partial save completions. Specifically on Distribute Preliminary Map Products, I knew in advance who I was sending the maps to, but was unable to enter and save any information until the actual date they were sent came. With this particular screen a lot of info has to be entered, and I like to do a “save” part way through in case something occurs and prevents me from completing the entry. Answer The ability to save partial data on the Distribute Preliminary task is not currently available. Users can save and close between adding communities, but cannot enter and save information about a specific community until they know the date the preliminary maps were mailed. A change request was created for possible inclusion in a future service pack. Issue/Question I have an issue with the implementation of the new FAFS 1301 Error check for the DFIRM database. A list of flood hazard line types was provided as being valid for SFHA polygons in the documentation for this 1301 error check. Upon implementation of this check in the FAFS automated reviews we are seeing lots of false error calls that are stopping studies from passing this stage. Will these errors be fixed soon? Answer The decision to automate the tests in the geo-spatial environment requires validation of the feature topology. We recognize the current documentation does not fully specify tolerances for complex geometries. However, per FEMA's Guidelines & Specifications Appendix K - K.4.2.1, 0.2 PCT floodplain areas that are very thin and are subsequently called as Error 1301 will be manually passed. We are working with FEMA to define what topological limits and artifacts are acceptable in digital DFIRM data. Issue/Question I’m seeing a lot of these items as sliver polygons and the check was intended for flood hazard lines, not sliver polygons. FAFS has a check for sliver polygons as a warning in another check. It seems strange that the 1301 check is doing more than initially described and now being called an error vs. a warning. I suggest 1301 check be changed to a warning. Answer Since the automated checks were formerly done by an analyst, this requires us to set tolerances at the data set level, which picks up the narrow features (sliver or portion of polygon that tapers off). This is a much finer check than during visual process. We recognize the test is to check for proper line type coding, but we have to perform against the topology. At this time, the results of check 1301 will remain as an error so that line type coding errors are addressed. However, per FEMA's Guidelines & Specifications Appendix K - K.4.2.1, 0.2 PCT floodplain areas that are very thin and are subsequently called as Error 1301 will be waived. The MIP team is going to have to revisit with FEMA and FAFS how the check was developed, determine whether we can expand those tolerances, and update the documentation, as appropriate. If you currently have this problem, contact MIP Help and we will work towards individual resolution. Issue/Question 1302 error check - Describe how it is determined if a line is an undershoot or an overshoot? Does the check stop at a single polygon? Why is it called as an error? What about breaks at a floodway? Answer Check 1302 does currently not handle BFE lines that snap to zone breaks IF the polygons on both sides of the zone break are AE or AH. For situations where zone AE polygons are adjacent to zone AH polygons with a zone break between them, BFE lines may terminate at the zone break since the zones describe two different flooding sources. This scenario was not considered when developing the logic for error check 1302 nor did it occur in the test data sets. A change to the software will be required to allow this situation to pass. In the meantime, a user should submit a help ticket stating that the error is being called incorrectly and provide an explanation of the representation of the features identified in the error report. MOD will review the error(s) and explanation, and if a false error is verified, FAFS will be instructed to bypass the error. The error report will be updated to "Passed" along with a return XML report to the MIP which updates the workflow and allows the MP to advance. Check 1302 will also call BFE lines that terminate at a zone break that divides a flood area that is coded the same on either side of the break if the break is not coincident with a levee or other general structure feature. Furthermore, if a BFE line snaps to a Zone Break between two AE zones, and both have no static BFE, and there is no general structure feature, it will fail. If there is a levee or other structure dividing the zone, BFE lines terminating at the zone break would make sense and will pass check 1302. Issue/Question 1303 - BFE's in different zones snap to a zone break at the same place. Why is this not allowable? Answer The BFE's that end at Zone AE/AH boundaries should be allowed to pass. We are looking into how the logic for check 1303 should be revised to allow this condition. In the meantime, these errors will be manually passed. Issue/Question I’m producing revalidation letters and noticed odd items popping up on the letter – suspended or closed cases. They include older cases that started with first SOMA tool. I either have to redo the entire SOMA or have to contact MIP Help to intervene. What do you suggest? Answer Legacy projects had multiple case numbers, depending on the community. Records are still stored by that CID from when the SOMA was previously filled out, but the case that was initially used to fill it out is no longer available in the tool because it was marked as ‘Removed’ as part of the update. This issue needs to be handled on case by case basis. The best way is to send in case numbers to MIP Help to fix the issues.