Description Key Coding w/Wildcards

[Anonymous]

C3D 2016 Win7

Hi,

How can I get description keys to work on similar codes. It is easiest to use an example:

MH = generic manhole

MHE = electric manhole

MHST = storm manhole

code may include additional info, like MHST.48

if I use codes as follows:

MH*

MHE*

MHST*

will MHST.48 come in according to description key parameters defined for MHST*? If not, how can I set up the description key codes to make this happen?

I cannot change the point codes.

thanks

[rl_jackson]

Yes the MHST.48 will allow the MHST Point to come in. What is the .48 for, and if your planning on using that in the point description use a space instead.

EX: MHST 48 where point descriptin would be $1" Storm Manhole and would read 48" Storm Manhole in the drawing.

[rl_jackson]

Better Example same principal

[BrianHailey · Accepted solution]

In your example, anything that starts with MH will be coded as a generic manhole UNLESS the next letter is an E or the next two letters are ST. 

MH=generic

MHX=generic

MH1234=generic

MHE=electrical

MHEX=electrical

MHE1234=electrical

MHST=storm

MHSTX=storm

MHST1234=storm

MHS=generic

MHET=electrical

At least, the five minutes of testing since I first read this post indicates this is how it works.

Hope this helps.

[Anonymous]

48 would be diameter of structure. there could be any number of attributes to any number of codes.

we use a decimal because plot codes are seperated by spaces.

so again, MHST -or- MHST.48 would come in on the MHST* layer, and not MH*? how does it know that the "ST.48" after "MH" is not covered by the wild card in desc. key MH*?

[Anonymous]

thanks, Brian,

I believe that this answers my question.

[BrianHailey]

---

@Anonymous wrote:

48 would be diameter of structure. there could be any number of attributes to any number of codes.

we use a decimal because plot codes are seperated by spaces.

so again, MHST -or- MHST.48 would come in on the MHST* layer, and not MH*? how does it know that the "ST.48" after "MH" is not covered by the wild card in desc. key MH*?

---

I think it's because there's another key that matches it "better".

[rl_jackson]

48 would be diameter of structure. there could be any number of attributes to any number of codes.

we use a decimal because plot codes are seperated by spaces.

so again, MHST -or- MHST.48 would come in on the MHST* layer, and not MH*? how does it know that the "ST.48" after "MH" is not covered by the wild card in desc. key MH*?

If you intend on using the 48 as part of the point description you will need to use a space, the period will not work with description keys. The intent of the wildcard is for additional descriptive information in the point label, as I showed in my screen shot previously using a similar description key with the FD........, anything placed after this must contain a space, this defines its position in reference to the $0 $1 $2 scenario. (i.e. FD*=$0) anything else would be count up from there, so a raw code of FDCIP 1 LS1234 would have a key of FDCIP* and a point description in the key of Found 1" Capped Iron Pipe "LS1234" where 1 inch would be $1 and LS# would be $2.

If you plan on using multiple attributes for a single manhole (I'm assuming your intending to place measurements to inverts), you'll need to define a new point file format the would be comma delimited for the with additional attribuites defined using the Point - User Defined Properties, as additional fields above and beyond your PNEZD so your would need a PNEZDA1A2 etc.....

HTH

[rl_jackson]

48 would be diameter of structure. there could be any number of attributes to any number of codes.

we use a decimal because plot codes are seperated by spaces.

so again, MHST -or- MHST.48 would come in on the MHST* layer, and not MH*? how does it know that the "ST.48" after "MH" is not covered by the wild card in desc. key MH*?

If you intend on using the 48 as part of the point description you will need to use a space, the period will not work with description keys. The intent of the wildcard is for additional descriptive information in the point label, as I showed in my screen shot previously using a similar description key with the FD........, anything placed after this must contain a space, this defines its position in reference to the $0 $1 $2 scenario. (i.e. FD*=$0) anything else would be count up from there, so a raw code of FDCIP 1 LS1234 would have a key of FDCIP* and a point description in the key of Found 1" Capped Iron Pipe "LS1234" where 1 inch would be $1 and LS# would be $2.

If you plan on using multiple attributes for a single manhole (I'm assuming your intending to place measurements to inverts), you'll need to define a new point file format the would be comma delimited for the with additional attribuites defined using the Point - User Defined Properties, as additional fields above and beyond your PNEZD so your would need a PNEZDA1A2 etc.....

HTH

[Anonymous]

My big question with spaces is how you incorporate plot codes?

if you had a 24 in. curb and coded TC 24 ST (for start line) for the beginning of a 24 in. top of curb - will that work? what about underbars? I've got my field people trained to NOT use spaces because of the way Inroads imports linework.

I work with other agencies that use Microstation, and I *have* to have spaces before plot codes as our city wide standard.

[rl_jackson]

With C3D the raw description delimiter is locked to just one or the other You can change the defaults in the linework code set, (i.e. B or BEG to ST) The field delimiter by default is a space, so if this is change it affects description keys as well, its all relevant.

[Anonymous]

Resurrecting this topic. The description keys work fine. Today's question is this:

How do I get point groups to behave similarly? My Sanitary point group (ex. MHS for Manhole, Sanitary) includes storm sewer points (MHST, Manhole, Storm).

Is there a way to have it differentiate between MHS & MHST? I am using Raw Description to sort the points into groups. The obvious way that appears to me is to Exclude points with raw description MHST*. But it'd be cleaner and easier to have a global setting, obviously. Is there such a thing?

[Anonymous]

point group problem solved by using Exclude tab.

same issue with survey figures using wildcards. BS=buried sanitary BSS=buried storm sewer. survey figure BSS1 is going to figure BS* (buried sanitary)

[rl_jackson]

Survey figures don't use a wild card. The figure prefix is just that a prefix. You need to have different codes like BSS and BST. Then your figure prefix should be the same as the code.

Sometimes less is not always better when doing figure prefixes.

[rl_jackson]

I would also recommend that for your storm and sanitary point group issue so you code MHST or MHSS

[Anonymous]

They apparently *d0* use wild cards. Unless they don't need the asterisk to behave the same way? All I know is that BSS1 (storm sewer) went to the BS (sanitary) figure.

I work for a city with several autonomous agencies. We all share data. Any change in coding would have to involve everyone. I can always suggest it, though.

Thanks for the input.

[rl_jackson]

BSS and BS will require a code change. There is no question in that. Figures have worked the same way with respects to prefix since the DOS days.

What is happening is it's seeing BS and stops reading anything after that hence the reason there called figure prefixes