How To Scale Symbols from a Shapefile?
I was able to do this using an intermediary file.
Map Import all your data into said intermediary file, then query that data into your target file. In the query, you can set the properties to alter.
This is just a sample from one of my generic files, but it shows where to make the change and what you can use. If you have object data, you'll have that option in the Property Alteration Expression dialog too.
You could add the local folder of the ACC path ("C:\Users\username\DC\ACCDocs\CompanyHub\ProjectName\Project Files\Folder\to\GIS\Data") and that *should* work.
I use a similar method for adding autocad settings to my profile and hosting the data in ACC.
Hi @Cadguru42,
@O_Eckmann shows a good way >>>Here<<<.
Description Keys will do this, but you might need some Excel magic to order things to be able to scale the blocks. Post a sample of your shapefile.
Dave
Dave Stoll
Las Vegas, Nevada
NVIDIA Quadro P5000 16GB
Windows 10 Pro 64 / Civil 3D 2027
Two options. First option uses MAPIMPORT with a plain vanilla AutoCAD annotative block. Second option maintains shapefile symbology and uses the shapefile's Style Editor. Neither option uses AutoLISP.
Option 1:
Use MAPIMPORT command. This command will convert the Shapefile objects into vanilla AutoCAD objects. Since your Feature Class is POINT, you can use a vanilla-ish AutoCAD BLOCK that'll replace the shapefile symbol. You can use an existing block or copy-and-paste one from another drawing (or from your personal block library). An existing block OR a block that's inserted right before MAPIMPORT will create a block definition in your dwg. Without a block definition, you won't be able to substitute an AutoCAD block that can stand-in for a feature class's symbology.
<<Don't confuse a BLOCK with a BLOCK DEFINITION. You may (or may not) delete the block after inserting it and this procedure will still work. Deleting the block doesn't remove the block definition, it merely removes the block symbol from modelspace. If you want to delete a block, first delete the block symbol, then use the PURGE command to delete the block definition.>>
Use MAPIMPORT to import the shapefile. Under the Data column, you may add Object Data (OD). Under the POINTS column, you may insert an annotative block by using 'Create as blocks' option. Then select your block from the dropdown menu. If the block isn't displayed in the dropdown then your drawing doesn't have that specific block definition.
Once MAPIMPORT has been executed, you won't see any blocks. Why? Because the blocks don't have an annotative scale. You'll need to manually give the blocks an annotative scale. When properly scaled, the blocks will react to the annotative scale of your drawing. If you Created Object Data (OD) during the MapImport procedure, you'll be able to see the (OD) when you select a single point and scroll to the bottom of the Properties Palette.
Select All (SA) then give all inserted blocks an annotative scale.
<<Alternatively you may manually insert a dummy block on the target layer=>Select the dummy block=>Right click=>Select similar=>All blocks on the layer will be selected=>Go to Properties Palette=>give all the blocks an annotative scale.>>
This option is the easiest, most straight forward option. It uses blocks instead of shapefile symbols. The size of the blocks are managed by the annotative scale in AutoCAD. If there's a drawback, it's the inability to store data. Yes, a block has attributes, but the shapefile has a database file (dbf) and it's still KING!! With the dbf, you can create a theme, use it to perform analysis, query the data to isolate or customize symbol appearance, and much more.
Option 2:
You can scale the shapefile symbol so it's the same size as your AutoCAD annotative block.
Example: I have an annotative block. The block is shaped like a circle with a radius of 0.05-feet. I would like the shapefile's symbol to be the same size as the annotative block. My modelspace has an annotative scale of 1:30. The calculation begins with the block's radius of 0.05-feet, or the radius used when the block was originally created. Additional variables include the width and height of the symbol that'll make it consistent with an annotative block and annotative scale assigned to modelspace.
Size context=Map
Units=Feet (your units may vary.) For Width and Height use an expression.
<<In a shapefile where points are represented by a circle, Map3D scales the circle using the diameter, not radius.>>
This method uses the symbology of the shapefile. It does NOT use an annotative block. What does this mean? It means the symbols (the circles) do NOT behave like annotative blocks. So.......If you change the drawing scale, for example from 1:30 to 1:80, you'll need to manually edit the FORMULA in the expression.
Chicagolooper
I don't need them annotative, but the 2nd option working on the shapefile helped! I didn't see the Expression options on the width & height before, so I wasn't sure how to do this. Autodesk should add an ellipse button next to the Width & Height fields instead of a drop down. I didn't think the drop down would have an option for Expression. Not the same UI ethos for the MAPIMPORT dialog where a drop down & an ellipse are present.
But the expression editor kept changing what I put in, though. I had DBH * 3. Then I'd go back because I realized I forgot to change Size context to Map, but the expression changed to some odd, decimal number * DBH. Took a few times of putting in the same expression to get it working.
Now I have to add a text label that shows the size then figure out how to explode all of it back down to dumb ACAD blocks for the trees and MTEXT objects.
So why doesn't the wizard for the MAPEXPORTCURRENTMAPTODWG show up? Is this a bug or has Autodesk changed that command for C3D users?
https://help.autodesk.com/view/MAP/2025/ENU/?guid=GUID-B78F42E1-9EAA-43AF-A6B1-42119E23E0AF
This wizard doesn't seem to exist for C3D 2026.2.
EDIT: Turns out there's another command that has this wizard named MAPTOACAD. So after creating an export template to get this exported it didn't keep the scales of the symbols when it converted to their blocks.
😠
As mentioned by @Pointdump Description Keys can be used.
See if this video helps. I've seen where the Description Keys were also set to adjust a trunk size. Gut that was many years ago.
https://www.youtube.com/watch?v=uUda2xA90Q4
Allen Jessup
CAD Manager - Designer
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 should add an ellipse button next to the Width & Height fields instead of a drop down.>>
I think they'll stick with that dropdown because it's what's used to write an expression for a Feature Class. That dropdown isn't being used to manage the size of plain vanilla Cad objects. If M3D is providing users the opportunity to manage a Feature Class with a dropdown, so be it.
<<I don't need them annotative, but the 2nd option working on the shapefile helped,,,>>
Although the 1st option mentions annotative blocks, the blocks don't have to be annotative. Non-annotative is fine. I mention annotative blocks because I find them easier to work with when I want to represent 'points' on a map. The 2nd option is excellent when you want to display the points as a feature class and gain the opportunity to leverage the shapefile's database.
<<...explode all of it back down to dumb ACAD blocks for the trees and MTEXT objects.>>
I don't understand 'explode all of it back down.' If you're going to explode why bother with the 2nd option? Use the 1st option instead, it's easier. Way more. When using 1st option, you're already in plain vanilla mode so there's no need to explode anything back down. Use 1st option if want easy to understand, intuitive conversion from from Data to Cad. Also use 1st option when working with users who are uncomfortable working with data, are unable to work with data, or refuse to work with data.
Using the 1st option also provides a way to populate a block's attribute using Object Data that was harvested during the import. It's a little tricky, but not that tricky.....so in the end you're already there.....with an attributed block and a corresponding label. MapImport: Not a thing to explode, not a thing to dumb down. Another way of describing Option 1: the shapefile's geometry never enters your drawing b/c all you need is the Database and the Geospatial Projection.
Chicagolooper
@Cadguru42,
"I'd have to figure out how to add [northing and easting] to the data"
Right-click on the feature in the Task Pane and choose "Create a Calculation". Then you can export the entire Table contents as CSV.
"going to use Dynamo to manipulate the tree blocks with data created by MAPIMPORT of the shapefile."
Let us know how that works out. Post up your DYN file.
Dave
Dave Stoll
Las Vegas, Nevada
NVIDIA Quadro P5000 16GB
Windows 10 Pro 64 / Civil 3D 2027
<<...I've got a shapefile of tree data that includes a field for size and common name. I need to have blocks scaled based on the size field, three types of blocks used based on common name, and have a label for each tree that says XX" TREE that uses the size field data.>>
If your shapefile has fields with
- Tree size (either canopy diameter or tree diameter)
- Type (bush, conifer, deciduous)
then it'll be easy to create a tree map. You could use either Option 1 or 2 noted above. I'd recommend option 2 because if the data changes, say an error with type or size, the change could be made in the shapefile's data table and the result would be reflected in tree's appearance on your map.
For example:
You can use 3 colors (your colors may vary):
- light green=bush
- medium green=conifer
- dark green=deciduous
You can use 3 different symbols too. Or you may use the same symbol for all tree since the color can indicate Tree Type.
The size of the symbol would be tied directly to the shapefile's database, since you have a field with 'size' data. The size field will determine the symbol's size.
If it were me, I'd make ranges for size. For example, for trunk diameter.
- <6"
- 6.1"-12"
- 12.1"-18"
- 18.1"-30"
- >30"
Your ranges may vary.
You could also make the symbol size on a one-to-one basis, where each individual symbol size is directly related to trunk diameter field. Be careful, though, many of the symbols will appear to be the same to the naked eye and offer little to help the audience the chance to differentiate one size from another. Ranges might not be ideal, but they offer the viewer to quickly see which trees are large and which are skinny. Even though it might not be accurate, the trunk size is commonly use to ascertain tree age and height, i.e. a young tree does not have a trunk diameter of 20" and a sapling won't likely be 3 stories tall.
If you maintain the shapefile and database, you can even create maps showing which deciduous trees are skinny and which are fat. Where conifers are dense and where they are sparse or nonexistent. Or you can make a map displaying tree size regardless of genus.
If you have data regarding tree Condition in addition to type and size, you can make even more maps. For example, if Condition is a field described as good, fair, to be taken down, and unknown, you can make a make map displaying which trees must be removed by the Dept. of Public Works and where those trees are located.
If your data also includes a field indicating Status, you may also map which trees are Protected and which trees aren't. You may also combine the fields Status, Type, and Size and map out which deciduous trees >30" are Protected and can't be removed without permission. Data is King. Why reduce good data to plain vanilla objects?
Chicagolooper
Based on your description, you can use MAPIMPORT on the shapefile. You can use plain vanilla AutoCAD block(s) to represent trees. If you wish, you can make all the blocks the same size and the same color. And MapImport doesn't care if it's an annotative block or a non-annotative one.
If tree size is a field in the shapefile's database then it can easily be your source to create Mtext labels. However it would be beneficial for you and others who work on the drawing if the labels were attributes of your block instead of Mtext. Using an attributed block isn't a requirement, it just make it easier to keep the label and the block together and not as separate entities.
If you have size size data you can, if you wish, populate the block's attribute with the size as it's listed in the shapefile's database OR you can simply insert Mtext for size. The MapImport procedure will easily make Mtext and make it plop down on the corresponding tree. Yes, you can use Mtext instead of an attributed block, but it might be less efficient compared to inserting the size as an attribute.
You can make your tree map as simple as you want or as sophisticated as the data and your imagination allows.
Maybe I'm not seeing the overall picture. A better description of your shapefile ( big wide screenshot of the shapefile's Table view) and detailed explanation of your deliverable would go a long way in figuring out the easiest and fastest way to get there without any hiccups.
Chicagolooper
I already gave the deliverable description. Just a simple, 2d drawing with blocks that are scaled according to the trunk size with an MTEXT label. This is to be a part of a base map drawing used for a water line design. We were given a shapefile from an arborist of the trees with some data.
I've got it partly figured out already using Dynamo. Below are some screenshots showing where I grabbed all the temp blocks w/data (from the MAPIMPORT), get only the blocks with "pine", "spruce", and "fir" in the CommonName field, then create blocks using the project standard block for conifer and have them scaled based on the trunk size * 3 scale (previously already done to the temp blocks).
I just need to do similar to the bushes and deciduous trees. Then create the MTEXT labels.
I did it using Dynamo. Here's how I did it ultimately.
- MAPIMPORT the shapefile with object data, use a temp block on a temp layer.
- Use Dynamo to take the trunk width multiplied by 3 to scale the temp blocks.
- Use Dynamo to filter all conifer trees, add the conifer blocks and scale them based on temp location and scale
- Use Dynamo to filter all bushes, add the bush blocks to drawing.
- Use Dynamo to grab all conifers and bushes, invert selection, then add the deciduous blocks and scale them based on temp block scale and location
- Use Dynamo to take trunk size, filter all non-zero data, get max bounding box X value of scaled blocks, subtract that from insertion X location, add one, then create an MTEXT object at that point that includes the trunk size value plus " TREE.
@Pointdump Here's the graph I used. Although, it's missing the original nodes I used to add the scale to the temp blocks.
