What features in C3D 2015 our customers are looking forward to:
1) Flipped Sample Lines / Cross-section views – missing feature in channel/river design projects
In channel design, river cross-sections have to be drawn in flow direction. This means that left bank is on the left side and right bank is on right side heading downstream. BUT river station starts from river mouth upstream. We miss the functionality (at least) to change direction of cross-section view or sample line. Similar feature is already done in profile view style. This is quite serious problem for channel design engineers.
2) Corridor daylight overlapping – projection lines overlap in tight corners. All workarounds are not effective and all the proceses are very laborious. Moreover corridors are better and more stable than gradings
3) Missing pipe design profile tools – all the pipe network functionality is useless without good profile design. Editing pipe section between manholes is very confusing and not very effective, when vertical design is changed. Many variables missing in profile view label style and in data bands. E.g. not possible to display elevation of invert anywhere (missing in crossing with other utilities) not possible to show depth of pipe invert from existing surface, expressions in data bands are missing. Part Builder is like from „another world“. Unfortunatelly, Civil 3D pipe design functionality is very poor and without any external application is insufficient.
4) Projecting objects to profile view and to cross section views – missing automatic intersection detection, where feature line / 3D poly / polyline crosses an alignment. According our standards most important location. Impossible to project polylines in profile view and in cross section views. They should work as utility network. In cross section view object projection is not possible to choose only some objects (NOT all 3dpoly/feature lines). Because all objects are projected, which is not as useful as it shoud be. Also individual styles for chosen projected objects would be very practical.
Is Autodesk able to implement such basic funcionality? Are these wishes crazy? These requests are from real world design...there is no need to make up some special features, that are not usually used. Just to improve, what is in the box...
Comparing several last releases I really doubt, that at least one of these suggestions will be accomplished.
you get the point, why argue about referencing method when its unbelievably fragile to begin with.
I cannot imagine having intermediate level cad operators do c3d labels, you need an expert on every planset.
This issue remains as one of my top 4 reasons (out of a long list) I would describe C3D unfit for production by non-experts.
And who has all experts at their office? Small outfits do.
This is the evil of C3D, where the good things in it are mixed with really bad stuff and it does not all even out to good.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Yes we are currently xrefing the parcels but with different usages, its a problem that it doesnt data ref. the map uses one style of parcel & labels while the improvement plans use another and often not at the same scale.
We use data referencing for alignments, surfaces, corridors, pipes etc. and for the most part, it works well for us. (we are a 25+/- employee civil engr. firm. we do small commercial lots all the way up to large retail centers and subdivisions.
I realize in the grand scheme of things that this is not such a big issue but when all the other major 3D features are data referenceable, why not parcels? its just a pain that shouldnt have to be. that's why it irritates me.
dumb!
Thanks Kathy, I was just fishing to make sure you know that parcels can be labelled through XREFs. The fact that you need to changes styles precludes the use of XREFs as you know already. Indeed, DREfed parcles would be beneficial in that case.
Kathy,
Can you comment on how your place handles making sure no one detaches an xref that might have labels using it?
Is it that someone sets up your sheets or exhibits and no one else is allowed to add or remove xrefs?
I would think once a company allows labels on xrefs, it makes detaching xrefs a dangerous thing to do, and hard to catchm mistakes on if there are only a few callouts using the xref that was detached.
Then there is the subject of API access, which only works on dref'd items, not xref.
Its the screwiest sharing system I could have imagined, yet so close to working if they would just publish the object data to an external source and have us hook to that instead. Its not like C3D is immediately dynamic anyway, you have to save a file for anyone to know your stuff changed.
Heck, making the objects publish as you change them would allow actual dynamic interaction, not that we need it.
The important stuff is ease of sharing and no cluttering of drawings with drefs we only need the data from when a callout is created or updated.
Hmm, LDT did this, Inroads, and every other prog that has worked well in the past, but C3D....gotta reinvent the square and call it a wheel....where do I stop.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
not that people need to hear more, but...
This issue of data access for labeling verses display of objects is perfect.
If Autodesk would make every object a data ref to an external database, then it becomes an editing mechnism as well as display.
You would not need drefs for labeling though, that would use the external database, which is the real data.
Or, if Autodesk let you "hook" to drawings with data, not xref or dref, then they would actually be delivering on what myself and several others THOUGHT the C3D team would do back in the beginning.
BTW, Bentley Power Civil does it this way, as well as having utility objects that are alignment based.
Carl better get ready for round two of C3D rewrite investment.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Not a bad idea, use layer lock as a flag that the xref has objects.
Hopefully you have a rouinte to do that for you (making and locking the layer for each xref), not all by hand.
I can help there if needed, our xerf tool does that for mutiple files at once.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
As far as losing labels when you unload an xref goes I know this was an issue but I do believe this was fixed in 2013. I just tested this by xrefing in a parcel and an alignment from a different file. I labeled some sta/offsets and parcel line segments. Unloaded the xref's, saved, closed, re-opend, reloaded the xref's and the labels were there.
John Mayo
Hmm, made me think I was about to eat words...but no.
I just tested on 2014 with alignments.
I did a few station offset labels, and they are gone if the xref is detached, or not found.
I did not bother to test with parcels or surfaces, and if its not right with alignments, I don't bother even looking.
I actually had someone that "preached" c3d tell me it was good for callouts to erase if the parent is gone.
I get the idea, that in a dynamic system things breaqk when the data is lost.
The issue is how they break. Proper behavior to real industry would be the callout becomes frozen how it last was, and some visual indicator showed on it to say its not alive but sleeping.
Then some way to rehook it gracefully if desired.
I bet you most people would not rehook the data given the current sharing and heavy update mechanisms.
You would add drefs to make callouts, then erase the dref's to rid the sheet of the slowness they cause on open and save.
That's what we do for c3d surfaces at our office, as we have our own labeling tools that keep their last state no matter what.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Sorry James I thought u meant 'unloaded'. If you unload vs detach labels stay. If you detached there is no object to label.
John Mayo
oh, I did not notice that. Good tip as that is useful for turning off the xref I may have only wanted for lablels, not linework display.
funny how we stumble on to things like this...
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
absolutely neilyj
It's like my kids, it is more fun to play a video game than it is to clean their room......
"Infraworks is great for "coneptual and visual stuff" I couldn't agree more. It is an incredible tool for doing just that.
It is unbelievable how little time is needed to build an acurate conceptual model.
However given that some design tools are being added to Infraworks 360, does it mean that there is a push to use Infraworks as more than a conceptual planning tool ?....only time will tell
But we have to understand that Engineers.......Civil 3D users, in the here and now, build stuff. That is what pays the bills.
So engineers need tools that will help them create designs efficiently.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
neilyj (No connection with Autodesk other than using the products in the real world)
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Autodesk will say "just wait, it will evolve there".
Since I claim I only complain in a constructive way, here are some issues to overcome:
You cannot currently "bring" in any dwg file and have it drape on the surface like a 3d xref.
Yes, you can do all kinds of data prep to get such linework, export as shapefile, and so on. But that is not practical.
You will need that desperately when doing any level of design.
So that basic is missing.
Then there is the idea, that Autodesk seems to want to forget, that real design is done in pieces that then are connected later to form something like a right of way or whatever constraint. Then we offset and play around until we have a realistic road or graded pad for a building. We (almost) never start off with a centerline that is then tweaked with grips, as that is not efficient.
So the drawing tools to construct those pieces and then merge into some realistic design, are missing.
Strike two.
The third issue is obscure, but important to anyone using GIS programs.
People ask what the difference between cad and GIS is, and I would say the main one is that you can have non-rectangular coordinate systems in GIS progs. I don't know the exact term, but Lat/Lon is not rectangular in terms of real distances. So a straight line in lat/lon, is some kind of curve on a projected state plane system.
I know these things are not noticable at the scales we deal with, but it screws up the whole idea of intersections and basic line/arc geometry that progs like acad have, as they are on a regular x/y coord system. I know people would say to ignore this one, but it will bite sooner or later when people realize you get all kinds of gaps and things when the data is pulled back to cad.
Then we have the problem that IW is an external database program, while C3D is not. This whole convoluted idea of data ref's in C3D, then import back and forth type sharing is just uncalled for.
If Autodesk would establish their object format, keep it external, then write display and edit mechanisms for whatever platform was needed, they would be on the road to BIM. They still have to redo the pipe network objects to be alignment based, but I think an external database approach would give them a changce to redo pipe networks.
Having written all this, I don't think the C3D team agrees with industry, that their program is half done. So why trust anything we say?
I think the money handlers at Autodesk do not realize they need C3D, part DEUX, so Dave Simeones team has their hands tied.
Lets hope that, because money solves that. Its so fragile though. Carlson or others could steal the market fast should they decide to fill the gap.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties