There have been many discussions about whether a user would want to manage points via description keys or by the new functionality with point groups in Civil 3D. There are reasons for both, but I’m thinking that through much research (and discussion with others, most importantly Anthony Governanti) I’ve finally got a best-practices of sort down in my head. Believe it or not, it utilizes a combination from both mindsets to work.
People who have talked to me about it before know that I suggest using only point groups unless you have a raw description that needs to be converted to a full description. For example, in my datasets, all trees are collected in the field as TREE[space]{tree diameter}[space]{tree species} and is converted to a full description of {tree diameter}”[space]{tree species}. I give a full description of this process here. I would use my point groups for display control over my points. It made perfect sense, since I only had 4 point groups. Lately however I’ve heard complaints about managing a high number of point groups.
Part of my reasoning regarding not utilizing point descriptor keys was due to a bug in the descriptor key editor display. With that panorama, there was a bug that kept the program from displaying all descriptor keys – you could only view or edit a very few (normally less than 5) at a time. I’ve been told, though, that the bug has been fixed in an upcoming service pack.
So, with that news and a pretty involved sit-down with Anthony, I finally drank the kool-aid. And here’s the solution:
Set up your descriptor keys. Use as many of them as you need (I’ve seen one client with 600+ keys in their set). Use them to set the initial point marker style (the “symbol” that comes in with your points), the initial point label style, and the point layer. Any number of other settings can be utilized, including symbol scaling options (use a key parameter, fixed scale factor, drawing scale, apply to X-Y, Apply to Z), and symbol rotation options (including using a key parameter, fixed rotation, and rotation direction). Best of all, this will apply the settings to points imported directly through a TXT or ASCII file and inserted from a survey database.
Now, if you want to change a label or point marker style on the fly, do it with a point group. Use the point style and label style settings of the point group to change how you’d want to view the point. What makes this easy is the fact that you can define a point group by a descriptor key. This makes selection very intuitive and easy to set up.
Using this process streamlines things a bit, and gets rid of some of the rather clunky UI when trying to manage large numbers of groups. Let me know if you try this, and how it works for you. Also, let me know if you’d prefer one or the other, and why. I’m interested in making this as easy for the end user as possible.
Have fun!
I agree with the concept of your workflow, but I have one major problem. For your system to work you have to have good incoming data with all of the raw codes exactly corect. If you get a bunch of points coded TRED then I assume that you have to go back to the source file to fix them and re-import.
You’re lucky – since it’s Saturday, I’m returning two comments for the price of 1 😉
1) First of all, NO survey crew will code everything right. This is due to crew apathy, lack of education on why accurate coding is so important, lack of enforcement on coding standards, or many other things. So, with that being said, we take you to comment #2 –
2) Both methods (descriptor keys and point groups) will allow for wildcards. This way, as long as the crew codes in the basics, the descriptor keys can pick up the rest.
So, this little snafu in the workflow is the same snafu that we had in the latest version of Land Desktop, the first version of Land Desktop, Softdesk, even DCA – they haven’t made a program yet that can accurately determine crew intentions via ESP 😉
Once again we agree; all surveyors – present company excepted of course – are either lazy or not very bright. The real issue here is how we deal with crappy data.
My solution is almost the reverse of Anthony’s. I use only one Description Key, which applies to all survey points and uses a $0 conversion from Raw to Full description. The result of this is to strip down the Full description to just the point code, with no comments or other values. I then have a point group for each survey code which matches on the Full description. The group name is the same as the code, and the program is set to create a layer named PGR [point group name]. So if I have a survey code EOP then all of those points end up in point group EOP and are on a layer called PGR EOP.
There are advantages and disadvantages to this method. I cannot display the point code attributes as part of my point label, and I don’t get the point symbols rotated and scaled by the description key. I do get all of my points on separate layers that I can isolate or freeze wihle I am cleaning up the data that I have imported. Any points that don’t fit any of my survey code list end up in the AllPoints group which I keep at the bottom of the point group list, and which uses a distinctive display style. This makes it easy to spot those points, edit them and then update all point groups to correct the problem. I also use point groups for proposed features like lampstandards or signs that I create within the program. This method has an unexpected bonus because I can right click on the point group name and select Export to LandXML to quickly create a layout point file for the survey crew.
After writing all of that I would actually prefer to use your method IF there was a way to process all points through the Description Key after they had been created or edited or whatever – the same way that Land Desktop does it. The Description Key system does have more options and better controls for converting a raw survey code into the point symbol and label that I want to see. I just want to be able to use it for all of the points all of the time.
Sitting here and writing out this response has been better for me than I expected. I had to really think about my methods, and whether I do things this way for good reasons or simply because I am stuck in my ways. Perhaps a little of both 😉
About surveyors being stupid or lazy:
The surveyor works in a different environment, is out in the dust, pestered by heat or cold, insects, noise, very different to the designers air-conditioned office. So typing in a code that is not quite right seems the least of his problems, as long as the measurement is correct, give the guy in the office something to do anyway. Not the right attitude, but that’s what happens when you have staff dedicated to field and other staff dedicated to the office. We don’t, granted we are small enough to work this way, but the surveyor does the field work, then sits in the office and reduces his work and creates the basic plan. This has the advantage that he is the one dealing with his own laziness/stupidity in the field, and quickly learns to do the work right.
About Point Groups:
I agree more or less with Jason. We import points and assign symbols using description keys. These keys are pretty fixed, the guys in the field have printouts for reference if they need them, and the list is standardised to cover most types of surveys. We also have a second set of description keys for office generated data such as boundary reconstructions, building setout points etc. Field codes are uppercase; anything generated in the office (design) gets a lower case code. So a point coded PIN is a steel pin measured in the field, a point coded “pin†is generated from older data, derived some previous survey maybe, and it can easily be seen on the screen which is which for comparison exercises . Point Groups are easily created and deleted. This makes them ideal to organise data within individual jobs. So we have a point group Boundary containing “bdy†and a group Building “bld†points, these contain the design boundary points and construction setout. “BLD†points are existing buildings picked up in the field. Another group called Survey Control contains all survey control stations, defined by their field codes. Then we have a group called setout points, which is a collection of point groups Building, Boundary and Survey Control. The beauty of this system is that any new survey control station generated in the field, once imported quietly slips into the Setout group, so the next surveyor uploads the Setout group with all the latest data in it automatically. And it won’t contain the “BLD†points because we don’t set out existing buildings. We can also create a point group containing all field data and shift/rotate it relative to another containing design data.
We get away with 4-12 point groups normally on a job, we have about 200 description codes.
Now if we could get Carlson Connect to recognise Point Groups, that would be really great….
Jason,
How do you change Point Styles using Point Groups for points whose description matches a code in the DescKey table?
For example, “NG” is in my DescKey table, and the points with the code “NG” come into the drawing with the correct symbol, etc.
I also have a Point Group that includes only points with “NG” raw description. If I right-click on that point group and select Properties, then change the Point Style to something else, nothing graphically changes on the screen…
So, can you have both point groups and descriptor keys active and displaying customized symbology at the same time? I am in C3D 2008 and my customized point styles have reverted to the marker style on the re-importation of my point file. For example, I made a customized style to represent a landscape boulder (from a correctly defined block). When the drawing was reopened after being closed, the boulder symbol was gone and the screen displayed the marker symbol. Do I need to now create a point group for this one item? Why was my point style overridden? How can I force my preset point styles to be current?(They took a lot of work to set up). I realize that it is Friday and I am tired, but what am I missing? Any help would be greatly appreciated.