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.
I will present these questions to other personnel for further clarification and possible follow-up. In the mean time, I will do my best to respond.
All project files are inclusively a part of a “PEDDS” or ED (Electronic Delivery) projects. All files in the delivery are uploaded to the PEDDS database server file store, in the FDOT local district offices. Many new projects begin as PEDDS deliveries and as fewer and fewer “Green Field” projects are constructed; more and more will start this way. Our goal is to standardize as possible and collect/provide accurate data in this process. I know it seems that the ED process is a one-way street, and you might have to think back to paper plans processing to think otherwise. The ED process is intended to translate the paper process into an electronic process and there “lies the rub”, it does not translate easily. Also, the workflows and standards are controlled by many outside forces. The intention is to standardize CAD data so that it can be used over again.
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.
I cannot respond much to this, but will pass it on. Scanned images do create very large files in the range of 20 to 30 MB. If your files are larger, I will be glad to take a look. I encourage feedback.
Strung Projects. This can be the easiest or the hardest process to complete. Add revisions to the project and forget it…
We are aware of the difficulties in this area and are considering alternate solutions. We must present these ideas to upper management and several technical committees for approval; unfortunately even if we agree on the issues, the solutions are more elusive. One solution kicked around is to eliminate Strung Projects and delivery only the changed sheets in a revision. Again, a change of this magnitude is not made at our level (as in me or ECSO).
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.
Green is a happy color and that’s why I’m using it now. Kidding aside, Green indeed does indicate everything is (to the best of the application’s knowledge) good and red means something is not right and should be corrected. Amber means a change was made, but does not generally indicate an error.
It is not our intention that you should have to respond in the journal to warnings (the color Amber). I am assuming that you are referring to EDI and FileChecker. With a little more specific information, we could attempt to clarify this for project managers. For one possibility, FileChecker has a disclaimer that could be reviewed and updated. I encourage feedback.
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.
Yes, very good point. It is headed more in this direction.
Why PS files and not just sign and seal the pdf.
We are working on this too. Quinton Tillman is a big advocate and our office is actively pursuing this, as are other FDOT offices. Technically, it is possible to create individual PDFs for each and a composite Project.pdf for the entire project, but Signing and Sealing is still accomplished through PEDDS.
Standardize the ED process between districts. Currently there are different standards for different districts.
We would love to. There is a balance of power between Central and Districts Offices. The authority for reform is above our pay grade, but we are staunch advocates and work toward this end. There are probably too many areas of concern, but if you provide specifics on issues you want us to look into, we will. I encourage feedback.
As you mentioned earlier, revisions.
Revisions do merit additional attention. I only know of few people that know the entire process by heart. Everyone else, including me, requires step by step instructions. The best source for guidance is the FDOT Electronic Delivery Course Guide. The guide is dated, but still provides the necessary information: http://www.dot.state.fl.us/ecso/downloads/documentation/EDTrainingGuide/Files/EDUpdate.PDF
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.
We try to limit updates to twice a year. It does not always work out that way. Forces beyond our control may force a higher occurrence.
We are struggling to insure quality data is collected and retained for future consumption. For better or worse, more and more data is collected and much will not be usable in the future. The reality may not be living up to the “Vision”, but we are using the existing data the best we can and are striving to improve. New initiatives are on the horizon for collecting more GIS data and modeling for automated machine guidance.
I think compliancy will take on a different aspect when modeling is the norm. I agree design software is increasing complex; hopefully, over time more emphasis will be placed on design and safety as design software evolves (albeit probably long term).
I will pose the question of longevity and use to others and respond later. I think you may be pleasantly surprised with the system for reuse of data (at least I hope so).
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..."