MAPIMPORT not drawing on correct layer when using data field for layer name

[mary_hayes]

I'm having an issue where when I import a shapefile, it will not put the objects on the correct layer based on the attribute data, but instead places all of the items on the current layer.  Is there a reason AutoCAD would ignore this? Thank you in advance. 

[ChicagoLooper]

Hi @mary_hayes 

Yes, there's a reason. 

You need to CREATE OBJECT DATA in order for Map3D to USE object data. This is how you can HARVEST the data from the shapefile's database file (DBF). 

<<When you harvest the shapefile's data you are  Creating Object Data.>>

In addition to Creating Object Data, you'll also need to tell Map3D which attribute in the Shapefile's database (DBF) you wish to separate. M3D will automatically create separate AutoCAD layers and place each individual imported ESRI object on it's proper AutoCAD layer. 

[mary_hayes]

I've already done that, and the object data is being imported. That's not the issue I'm having. I want the objects to go on the correct layer based on the value of make ready, but the value of make ready does not affect the layer they're being drawn on. I'm trying to follow this process, but I'm not getting the results I'm intending. 

Importing shapefile into AutoCAD Map 3D? - Geographic Information Systems Stack Exchange

[ChicagoLooper]

@mary_hayes 

This is how you do it.

What are all_points?

What's the Feature Class?

Are they Points? Or Lines? Or Polygons? You didn't mention your shapefile's Feature Class.

If they're POINTS, be forewarned........the procedure above will insert the shapefile point Feature Class as plain vanilla AutoCAD points. If you don't want points and want the feature class inserted as BLOCKS, then you'll need to give Map3D additional info. Since you didn't mention whether you'd like all_points inserted as Blocks or inserted as vanilla points, the procedure above assumes you want Acad Points. Plain vanilla points, not blocks. 

<<If it were me,  I'd insert them as Blocks. And not just any ol' blocks, I'd use an AutoCAD Attributed Block so I can give each individual block an appropriate label. I know this procedure works when inserting either plain vanilla points w/o labels or blocks with labels because I've imported shapefiles using BOTH methods. If this work flow still doesn't work for you, you'll need to share more screen shots of your shapefile's database. An examination of the DBF data as it appears in rows and columns will provide more info regarding your data, which in turn, will allow a more descriptive step-by-step procedure. Better yet, can you share your shapefile?>>

Sharing your shapefile would be the fastest and most effective way to resolve your issue.

[Pointdump]

Hi Mary,
What you're doing should work. Can you post a drawing and data?
Are you current on updates?
Dave

[mary_hayes]

They are all points. They are being inserted as blocks, but I get the same issue whether or not I use blocks or vanilla points. I can't share the drawing itself since it's proprietary, but I get the same issue with a blank drawing, as well. Here are all the files made when I export the data from QGIS. 

[ChicagoLooper · Accepted solution]

Hi @mary_hayes 

Thank you for sharing your data.

Your issue is the shapefile itself.

When you MAPIMPORT all points.shp you have a 'space' between all and points. That space is fine-and-dandy for the shapefile's Name but the Attribute named make ready is a different story. Although the Map3D's MAPIMPORT procedure shows an _ (underscore) between make and ready, there's actually no underscore in the shapefile's database. That underscore that you see when using AutoCAD's MAPIMPORT was inserted by the import procedure, not the shapefile's author. The shapefile's author forgot that attributes shouldn't have spaces because spaces may introduce undesirable consequences to the next user. 

It's a BEST PRACTICE to avoid all spaces in your attributes when creating a shapefile's database file (DBF). Replace any spaces with an underscore or dash.

To verify you can open the Table View using another GIS-essy program to see whether there's a space or an underscore. For example, when I use the program

Global Mapper, there's a 'space' which suggests AutoCAD M3D is inserting an underscore on its own due to that offending 'space.'

1. Shapefile opened in Global Mapper.

Back in Map3D, I open the same shapefile as a shapefile using an FDO (Feature Data Object) connection, where the attribute is readable in the Table View. In the image below make ready is readable despite a 'space' between make and ready. While shapefiles can handle that space the MAPIMPORT procedure in Map3D cannot.

2. Shapefile using FDO connection in Map3D.

SOLUTION:

I would suggest you EDIT the name of the shapefile's attribute using QGIS, Arc Pro, Global Mapper, OR any other suitable GIS-essy program. You may, or may not, edit that shapefile's attribute using M3D's BULK COPY command. It's up to you which program you want to use. Just be sure to make the edit. To be clear, the solution involves replacing the offending space between make and ready with an underscore.

<<BTW, the Bulk Copy procedure in M3D is certainly doable, but it's clunky, meaning M3D will make you jump through hoops to complete it. Don't worry, the hoops are really big and you won't have any issue going through them. It's just the act of jumping through them is what makes it clunky, compared to 'no jumping' using other programs.>>

For the blocks, if you want to use blocks to represent your points (all points.shp) there's a catch. Actually two catches.

1. The first catch, you'll need to insert the specific desired block into modelspace first, before running MAPIMPORT. Inserting your block will invariably create a 'Block Definition' for that block. Without that block definition, MAPIMPORT won't know what to insert. Believe it or not, you can even DELETE the block after inserting it. Why? Because the definition STILL exists despite that deletion. If you really want to delete the block's definition, you'll need to run the PURGE command. Just 'establish' the block definition and you'll be fine.
2. The second catch is to make sure your Block has an ATTRIBUTE TAG named make_ready. That way the make_ready value in the shapefile can JUMP into the make_ready attribute in the Block. Yeah, it's confusing because there's an attribute in the shapefile and there's another attribute in the block.....and BOTH attributes are named make_ready! (Say that five times fast w/four fingers in your mouth while jumping through a hoop.) Those attributes have to have the SAME name with that SAME funky underscore between make and ready. Without identical attribute names and underscore, the jump from shapefile-to-block can't happen. Won't happen. Be sure to edit the Attribute Tag in your block so it's identical to the shapefile's attribute.  

Your site, correct?

3. Three layers in the Layer Props Manager. In modelspace, three different colors for the block. Bing aerial imagery in background.

[Pointdump]

Mary,

Thanks for posting data.
@ChicagoLooper is right. If you add an underscore between make and ready, which I did in QGIS, it works as expected. With a space, it goes on layer 0.
Dave

[mary_hayes]

It works now! Thank you so much for your help on this.