EDI is complicated, no doubt. The design for the Electronic Delivery process began in the late 1990s with EDI originating shortly thereafter. I'll admit, I would not have liked working with the first series of releases. Somewhere around 2003, EDI2 improved processing somewhat (plotting added). Over the years many issues were reported and resolved; Also, EDI was adapted to each new release of MicroStation and now PowerGEOPAK. I do feel the most recent release for the FDOT2010 MR2 software, works as intended, and significantly better than previous versions.
EDI's complexity is due to the Electronic Delivery workflow, the increased sophistication of the MicroStation products, the evolution of the FDOT software including EDI, and the dependencies of everyone and every related process. I feel compelled to confess, almost every change request over time was included as a feature in some way or another, and EDI fits the saying "all things to all people", too well.
However, for the most part, the overall process remains steadfast:
Yes, revision processing is a definite shortcoming and very large projects are another weakness for EDI. Hopefully, future changes can improve upon these areas. The good news is, not as many calls for support without a clear response are reported. ECSO Support does have the answers.
Question: For now, assuming EDI will not change in a big way (requiring redesign of the whole ED workflow), what specifically can be done to make your EDI processing experience easier?
Advice: Since only one or two ED projects occur per year: 1) Start early, 2) collate your project data carefully and 3) test create the required products several times, throughout the life of the project. If you run into problems, call ECSO Support for help ASAP. ECSO Support is glad to help and can get you going in almost every circumstance, but it may take a day or two. The most difficult calls seem to come on Friday afternoon before a holiday weekend, a day or two before the project is due. This is not a criticism, we really want our products to work well and help you create high quality results. Your feedback is essential for improving our products.
I am asked this question every time we start the PEDDS process sitting in a conf room cross checking hundreds of hash codes and manifests. Where do our files actually go and who uses them? Since the inception of ED in the 90's has moving to this electronic delivery process helped anyone? A few things we have challenges with and feel the process could be tweaked.
•Existing Bridge Plans having to be added to the ED Project. Most of the time these are scanned plans from bridges designed in the 40’s so your taking 24x36 plans reducing them to 11x17 and scanning to pdf and inserting into EDI. The result is a huge file that you can’t read because of the poor scan quality. I know it’s not a software design issue it’s just a process that doesn’t work well.
•Strung Projects. This can be the easiest or the hardest process to complete. Add revisions to the project and forget it…
•Why Green, Red and Amber in EDI. I say Red and Green, you can’t fix the amber most of the time anyway and we end up spending way too much time journaling.
•Design Build. We have produced 5 design builds but have not processed one of them through EDI. Brings up the question, do we really need to do all of this work in ED when all the contractor needs is a set of plans.
•Why PS files and not just sign and seal the pdf.
•Standardize the ED process between districts. Currently there are different standards for different districts.
•As you mentioned earlier, revisions.
•Cadd Software updates. We know it’s inevitable but this in itself makes the downstream use of 15 year old cadd files almost useless. Remember v7 to v8, a nightmare then v8xm to v8i well not a whole lot better with level and linestyle changes again not an EDI thing per say but well It Is.
If the intent is that downstream users would be able to use the cadd files we created for future projects I’m not so sure that’s realistic. On the typical Design Bid Build project that is designed in the 90’s won’t be built for 10 to 15 years. In that time frame the design standards have changed and in many cases the project topography has changed making the cadd design files outdated. I bring this up asking my first question again, who is using our files? Do we really need to deliver cadd files or is the signed and sealed PDF good enough?
Keeping in mind that many of us are roadway designers/engineers where our main focus needs to be on design standards and safety using the ever changing very complex design software. It would be nice to think that just keeping your cadd file 95% compliant was all that it took but its not.
I know a lot of the stuff I bring up is not so much “how to improve EDI” but if we know how our data is being used and what the shelf life is of that data then developing better processes to produce the EDI product will be easier and make more sense.
In addition to the previous response posted I received the following information from FDOT's Surveying and Mapping Office (SMO) in regard to GIS CADD data:
"...project datasets are delivered electronically to the Department via our published CADD Standards. Now the Department has developed a robust Geographic Information System (GIS) enterprise platform for displaying the GIS data. The integration of some or all Surveying/Mapping and Engineering CADD data w/attributes (bi-directionally) with the FDOT's Enterprise GIS ... is our goal."
Further insight in regards to critical training requested by the SMO:
"The training on this application software is critical to our mission and will be instrumental in developing the standards and documenting the creation/processing of Surveying and Mapping CADD data to our downstream customers including providing data to our new Enterprise GIS system. This is in keeping with continuing our mission and goals both here at SMO and the Department..."