Topic: FDOT C3d 2011

[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.