Topic: FDOT C3d 2011

[cadtag]

if anyone is interested,  FDoT is beginning to roll out their flavor of c3d.  I was not able to install since the .msi fails with an error if c3d 2011 is not in the OOTB location.  Corp does it differently, and by the response from FDoT, they are not interested in fixing it at this point.

http://www.dot.state.fl.us/ecso/downloads/publications/civil3dworkflows/default.shtm

[mjfarrell]

Looks like the results of trying to solve a problem that doesn't exist, thus creating one that needs to be solved.

Also of interest, that they are not allowing use of C3D for ALL production work, and only for use on selected pilot projects.

Sounds like those working with FDOT and C3D would be served well by better training with the product.

[alanjt]

From what I've heard, it's going to take a lot of the functionality out of corridors, etc. since FDOT's Entity Manager, etc. are written to function as old Microstation commands and any forward thinking from Autodesk gets ignored. A lot has to do with the way their QTO manager is set up.

[mjfarrell]

Your answer seems to amplify the need for training.

[alanjt]

Your answer seems to amplify the need for training.

Without a doubt. FDOTC3D isn't something you just pick up. We went to the initial/beta FLUG training weekend and it didn't even come close to explaining what you might need to know to use the software.

[cadtag]

Wisconsin DoT looks to have a beta for c3d 2010, and they too seem to go along with the fdot approach of making the adesk package work as much as possible as the bentley stuff -- regardless of loss of functionality.  Makes a bit more sense if you think of the DoTs as facility management organizations rather than engineering outifits, consumers of road data rather than creators, and needing any incoming info to feed into current systems.

of course, if WisDoT s beta testing 2010, and FDoT is beta testing 2011, when 2012 is shipping, it really doesn't bode well for the future of C3D in DoT work.

[mjfarrell]

It would be suggested that they simply use C3D as it is, and only use they data they want without dumbing down the data in any way.
Probably far easier to write reports with the data in the desired format, than to not use all of the tools to their full potential.

[BruceDana]

We invite you to give us (FDOT) a call about our implementation.  Contrary to what has been said here, we haven't removed any C3D functionality, and actually have extended it. 

On this one point, Entity Manager simply allows you to draw elements that will always land on the right Layer with the QTO data already attached, and XData also already attached so our subassemblies will automatically insert and target without the designer having to specify targets (again) in the assembly.  You select and draw entities by the objects that they are, that is you draw a "curb line,"  not have to hunt down a level that has an exotic name to draw the "curb line."

The only anchor to our long standing MicroStation Standards are we continue to use the same legacy (MicroStation V8) filename / Level(Layer) / Color / Weight(Thickness) / Linetype (Linestyles) / Cell(Block) CADD Standards.  It sure makes tanslation between system that much easier (if translation becomes necessary).  The National CADD Standard (OOTB Civil 3D) just didn't work for us.

As far as installation, we plan to improve that where our content will install wherever Civil 3D may be installed.  We tried to use the Autodesk Country Kit installer provided by Autodesk, but it couldn't do 2 critical things: 1) install applications, 2) install our content without intermingling it with Autodesk content - besides being buggy and not uninstalling correctly.  So we wrote our own install, and would love to get guidance on how to make our content (and Civil 3d) more location agnostic (Autodesk Consulting still has not been able to help us get there completely).  Again, please contact us - We would like some specific answers on how to improve this?

We'll also admit we could always use more training, but we've just about exhausted everything Autodesk has available.  If there was a CADD Manager's course that would help us focus on specific configuration issues we are having, and help get us over the hump of getting the install of our content where it could be installed anywhere, and have Civil 3D still work - that would be a benefit.  We're also working on  unifying our install so one msi will do both 32-bit and 64-bit installs.
Call us, toll free at (866) 374-3368 ext 1600 or visit us on the web at http://www.dot.state.fl.us/ecso/ and ask for someone on the Civil 3D implementation team.  Thanks!

[Mark]

Welcome to TheSwamp Bruce. Thanks for coming by and letting us in on what's happening at FDOT.

[alanjt]

Open mouth, insert foot. Big Brother is still watching.   

Bruce, that's wonderful to hear from an actual FDOT employee (especially one I met at the FLUG training last year) that Civil 3D will not be 'dumbed down'. As I said, it was based on hear-say and hear-say alone.
If what you say is true, I retract my statement and humbly apologize.

[mjfarrell]

Welcome Bruce.

Thanks for confirming what I've said since the beginning; that the NCS is neither National, nor the Standard and it doesn't work well for most other users either.
Also thanks for clarifying what FDOT was or has 'modified' within C3D for their needs.

[BruceDana]

We posted many of the presentation we did at the Region update training we did last Fall 2010 here:  http://www.dot.state.fl.us/ecso/main/FDOT2010RegionalCADDUpdate.shtm

This was a mixed platform presentation, so you will find some of the MicroStation related ones also.  Of course without a video recording, just the handout is less than the "live."

We intend to repbish the pages with the "State Kit" workflows before the end of June, with several additional workflows.  Our goal was to rely upon external resources for all of the fundamental Civil 3D workflows and operations, and only produce our own when we had something specific to set or something that deviated slighly from those you see in the Autodesk documentation or the very good books that are our there.

Also, we want input, criticism (good and bad), and help testing what we put out there.  We do not have the legacy of 25 years using Autodesk and Civil 3D for production like we do with Intergraph/Bently tools, and want to know where we can value add to Civil 3D to make it work well for transportation design in Florida.

[cadtag]

Thanks for the information Bruce,  but a comment or two that may be helpful (or not)

>>we plan to improve that where our content will install wherever Civil 3D may be installed.

That's not really going to help me all that much -- I truly do need any add-on, or vertical-of-a-vertical, to be installed in an arbitrary location, or failing that in  a pristing directory under Programs.  I'm already dealing with multiple client or company standards, multiple add-ons, etc etc etc.  I need to be able top run C3D either in pristine condition, company standard, for fdot, or for whatever other purpose/client/standard I need.  Any installation that forces itself into a application deployment is not good in my corporate environment (10k+ employees).  Rather rude of the installation, to put it one way.

Another comment is simply based on only being able to see the .dws files after extracting them from the .msi.   They seem (and since I can't access or run the FDOT C3D tools, it's quite possible I'm wrong) to mimic normal microstation practices - with per-object over-rides rather than bylayer.  If that's the case.....

And finally, how do you propose to handle the incompatabilities C3D has demonstrated between annual releases?  If you release a 2012 version later, how can any consultants working with 2011, 2010 produce FOT spec documents?  How can any consultants collaborate between firms, other than forcing themselves to stay in lockstep with FDOT releases - whether tha's on the current 2012, or 2011 versions?  Seems like Bentley products have a long history of file/entity compatability between versions -- C3D not so much.

[Dinosaur]

Thanks for the information Bruce,  but a comment or two that may be helpful (or not)

>>we plan to improve that where our content will install wherever Civil 3D may be installed.

That's not really going to help me all that much -- I truly do need any add-on, or vertical-of-a-vertical, to be installed in an arbitrary location, or failing that in  a pristing directory under Programs.  I'm already dealing with multiple client or company standards, multiple add-ons, etc etc etc.  I need to be able top run C3D either in pristine condition, company standard, for fdot, or for whatever other purpose/client/standard I need.  Any installation that forces itself into a application deployment is not good in my corporate environment (10k+ employees).  Rather rude of the installation, to put it one way.

Another comment is simply based on only being able to see the .dws files after extracting them from the .msi.   They seem (and since I can't access or run the FDOT C3D tools, it's quite possible I'm wrong) to mimic normal microstation practices - with per-object over-rides rather than bylayer.  If that's the case.....

And finally, how do you propose to handle the incompatabilities C3D has demonstrated between annual releases?  If you release a 2012 version later, how can any consultants working with 2011, 2010 produce FOT spec documents?  How can any consultants collaborate between firms, other than forcing themselves to stay in lockstep with FDOT releases - whether tha's on the current 2012, or 2011 versions?  Seems like Bentley products have a long history of file/entity compatability between versions -- C3D not so much.

A few years ago when I was still trying to use this turkey, I was exploring the idea of using virtual machines with each VM having its own installation and setup customized for a particular client requirement.  Along with a pristine OOTB installation I had one with a typical customized setup that could be cloned for each unique client setup.  I was having pretty decent results with this approach at the time and would recommend exploring it as an option.

[cadtag]

Din0saur --
that's an interesting take, and sure sounds workable if corporate will let people.  I would guess that would be organization dependent -- does the company IT have any interest/expertise in VMs, are they on control-freak lockdowns, let people actually work, or what have you. 

to BruceDana --
Since this development is being funded by taxpayer dollars, can we presume that the package being distributed is public domain?  If not, why not?

[Dinosaur]

We were about as small of a company as you could get - just 2 - the ITwit / engineerTwit and myself doing the office work.  I really can't see much of an obstacle though unless it would be in licensing.  We just had stand alone stations.

[mjfarrell]

to BruceDana --
Since this development is being funded by taxpayer dollars, can we presume that the package being distributed is public domain?  If not, why not?

NO.
Probably due to the original license rrestrictions made by autodesk

[cadtag]

to BruceDana --
Since this development is being funded by taxpayer dollars, can we presume that the package being distributed is public domain?  If not, why not?

NO.
Probably due to the original license rrestrictions made by autodesk

For anything that is a licensed modification of a proprietary autodesk file being re-distributed, that would be reasonable.  Might also be applicable if a 3rd party developer has been involved for segments of the package and fdot is authorized to distribute but has no other rights.    Autodesk doesn't own rights to your dwg files after all, or your dws, dwt, acad.lsp, etc.

But autodesk or other vendor restrictions really can't apply to the .lsp, .arx, .dll, .dws, .dwt, .shx/shp, .pat, .lin, or .ttf fonts developed by fdot on taxpayer time/money.  You paid for it already with your tax dollars. In that context it would seem to be no different than USGS Quad maps, which _are_ public domain.

[BruceDana]

Everything we produce in the State Kit for FDOT is available for use (link poasted earlier in this thread).  Our software is registered copyrighted by FDOT, but you can download and use it as you see fit.  One thing to note is that taxpayer funding doesn't make works by public entities public domain (perhaps a common misconception - like we live in a "free country" or that our government is a "democracy").  We do use a "disclaimer" to protect the Department and that will be more embellished once this thing gets out development and into an  initial release. These preview  releases are intended to solicit comment and input.

As stated, we would like input on how we can improve and make the installation more agile so it may be deployed easier and in a broader environment.  Note that our prime directive is to deploy for our needs in our environment, but if someone can point out, specifically, what we need to consider (registry / environment / etcetera) we'll try to incorporate that in future installs.  We'll be the first to admit we haven't spent a lot of time on custom installation support, and if anyone can point out some good resources we'll listen.

[BruceDana]

Another question I didn't yet begin to address is how FDOT plans to deal with the format changes between major database versions of AutoCAD/Civil 3D?  We've been thinking a little about that one, however the first reality even hits with the release of 2012 and our code development (done under 2011).  Albeit no major DWG database change in 2012, we still need to approach versions carefully from the development perspective too.  Our state kit has both net load applications running inside AutoCAD and .NET applications that interface to AutoCAD through COM.

We are just beginning to learn the dependencies to particular versions of AutoCAD and Civil 3D.  Up to now we focused on just getting what we thought was needed content and functionality in our code while learning to develop for AutoCAD, but now must begin to make our offering as version agnostic as we can.  We're depending on the API remaining "stable" and that ADSK doesn't completely obsolete our executables between subsequent or near subsequent versions of the platform.  Can you imagine if Microsoft did that? 

Even now as we built our stuff on 2011, since 2012 has been released we need to decide how to support it, and when?  Do we get to version 1.0 of the state kit on 2011, then concentrate on migrating to 2012?  Do we drop 2011 development now, and then switch the developers to 2012 before we get 1.0 out?  And so on...  We use MS Visual Studio, and there are issues between VS2008 / VS2010 and developing in C3D2011 and moving solutions to VS2010 and ACAD2012 that must be considered also.  I'll admit I'm no longer a developer and do not know all the details, but at least I know there are details    A goal would be to at least support the genre 2010-2012 with our first release.  Hopefully we be able to do that, and in the mean time our programmers have been asked to do what they can to achieve what version independence we reasonably can.

For consultants working for us, our standard scopes of work do address that they must remain contemporary with the department (standards, and for deliverables) unless that is negotiated out of the contracts (which it rarely is).  We are a little conservative in that we usually are N-1 versions behind the vendor releases...if that makes a difference?

[sinc]

Around here, we like to move to new versions in the winter.  I don't know if Florida really has a "winter slowdown", though...  In fact, the "winter slowdown" was rather theoretical this year for us in Colorado, and EJ Surveying still hasn't moved to 2011...

In any case, I think it's definitely a good idea to wait on 2012 until sometime after the first SP is released.  You don't want to be responsible for pushing everyone into a release before the known issues are worked out.

Do you have a timeframe for completing your v1.0 kit?  If you plan on completing it before this fall, then I'd say yes, definitely finish it up in 2011, then convert it.

I wouldn't expect it to be too much work to convert up to 2012, once you have things set in 2011.  We had minimal trouble getting the Sincpac-C3D working on 2012.  Far less trouble than the jump from 2010 to 2011, when Autodesk changed Superelevation and we had to rewrite a bunch of stuff in response.  Although all our stuff is in .NET, and I don't know if you'll have more trouble or not if you're doing C++ stuff.

[sinc]

Oh, and something you might want to keep in mind is that the really large companies don't like upgrading every year.  They have so many offices that, if they have to upgrade every year, it's time to start the next year's upgrade before they've even finished the current year's.  So they prefer to skip every other release.  You'll might want to expect some pushback in that regard from some of your larger clients.

[joshua.modglin]

Bruce,
As you mentioned there are so many details to consider regarding add-on development to AutoCAD and Civil 3D and since I have not gone thoroughly through all the information nor do I know the details involved regarding the needs, I can't speak in detail but would like to just make a suggestion.

The .Net API has been MUUUCH enhanced for Civil 3D for 2012. What this means is that, depending upon setup and usage, FDOT may be able to avoid any dependency upon working through a COM API (except if you have any out-of-process executables). The COM API is where version dependency is so demanding. In most cases, I can take a .Net DLL built for 2009 AutoCAD (using those DLL's as references) and it loads and works just fine in 2012. Thus, a look at the 2012 Civil 3D NET API is definitely worth considering when trying to establish Civil 3D version for final release.

Hope this helps (and hello  )

[BlackBox]

A goal would be to at least support the genre 2010-2012 with our first release.  Hopefully we be able to do that, and in the mean time our programmers have been asked to do what they can to achieve what version independence we reasonably can.

Subject: FDOT2011.C3D beta release notice

This is the last release for 2011. The next release will before Civil 3D 2012.

The software can be accessed here:
http://www.dot.state.fl.us/ecso/downloads/publications/civil3dworkflows/


Please report any bugs or enhancement requests at:
http://www.surveymonkey.com/s.aspx?sm=vpH3GFrro8xuDfrcuBSVFw_3d_3d


Please let us know if you have any questions?

Bruce, could you provide any additional calrification as to the change of deployment intent?

[sinc]

Maybe they discovered that supporting the three-year ObjectARX cycle is irrelevant and inapplicable when it comes to C3D...   

[BlackBox]

Maybe they discovered that supporting the three-year ObjectARX cycle is irrelevant and inapplicable when it comes to C3D...   

Perhaps. LoL

Hopefully Bruce will be able to elaborate; the email isn't exactly robust.

[BruceDana]

Next week we will participate in the Florida Local Users Group (FLUG) training in Cape Canaveral.  We have compiled the last version of our "state kit" intended for the Civil 3D 2011 platform.  That is called "FDOT2011.C3D" and can be accessed here:  http://www.dot.state.fl.us/ecso/downloads/software/FDOT2011C3D/FDOTStateKitDownload.shtm

It wasn't too painfull, but our development has now shifted further work on out "state kit" toward the Civil3D 2012 platform.  The next release of the state kit beta will be for that platform.  We will try and make it com-patable still with Civil3D 2011, however there are know differences such as with the new drainage application and how parts connect with Storm and Sanitary Analysis in 2012 - so it is a different animal.

As thing progress with the pilot projects here, we intend to bring further projects in on 2012 (and need to produce a 22010 "State Kit".  Our District 1 Office has a large project with lots of drainage, and desires 2012 for their work which is scheduled to commence in June.

[BruceDana]

The 2012 version of the "FDOT state kit" is almost ready.  We were able to make the install more robust where Civil 3D could be loaded in locations other than the "default" which should make everyone happy.  We're also trying to clean it up a little more where vanilla AutoCAD can be the target platform (for those trying to conserve Civil 3D license investments).  The installer now has no more hard coded paths (all variable driven now).  As we learn more about the administrative things we can get away with we'll keep improving the install.

Also, Nothing is ever as easy as you might think (just migrating our stuff from the C3D 2011 platform to the C3D 2012 platform, for example).  Another thing we did was redevelop most of our custom sub assemblies from .NET over to SubAssembly Studio (SAS).  Some, however like existing features SubAssembly will still be maintained in .NET exclusively for the time being.  We also wanted to try SubAssembly Composer (SAC) but simply didn't have the personnel available to get into it very much for now.  Like SAS, SAC also appears to have some real promise for those needing to do their own subassemblies, but it was retired from the Autodesk Labs this week (but hopefully will come back in a service pack to Civil 3D 2012?).

[BruceDana]

We think we have the 2012 version of the State Kit functioning, but are still testing...  If you see fit to try it out please use the link below.  It should not disturb anyone else’s existing Civil 3D 2012 workspace or content as we install nearly all of our content to a \fdot2012.C3D folder and run our workspace from a a startup icon which in turn creates a separate FDOT workspace (runs an ARG file).

The Link is here:  http://www.dot.state.fl.us/ecso/downloads/publications/civil3dworkflows/default.shtm

Let us know what you find (good or bad).  Hopefully the pilot projects we're underway with will demonstrate good functionality and the testing of this state kit will get us closer to production ready soon.

Thanks!

[BlackBox]

... Hopefully the pilot projects we're underway with will demonstrate good functionality and the testing of this state kit will get us closer to production ready soon.

For those who have been following this (especially those way back to the FDOT Civil 3D 2011 State Kit)... The FDOT Civil 3D 2014 State Kit Beta is available as of August 14, 2013, and can be downloaded here.

Cheers


[Edit] - Didn't realize there was a production ready release; see Bruce Dana's next post.

[BruceDana]

The first production version of the FDOT State Kit for Civil 3D 2014 is now posted:
http://www.dot.state.fl.us/ecso/downloads/software/FDOT2014CADDSoftware.shtm


Please let us know if you find issues with it.  We are always trying to improve it.  Comments, suggestions, and corrections are welcome.  It's best to e-mail the group at: ecso.support@dot.state.fl.us

Remember to uninstall any beta of the 2014 State Kit BEFORE installing the release version.  Check the Installation Guide on the link above for more detail.

Thanks !