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…

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

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

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