AutoCAD Map 3D Forum
Welcome to Autodesk’s AutoCAD Map 3D Forums. Share your knowledge, ask questions, and explore popular AutoCAD Map 3D topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Object Class createmethod codes for Hatch?

6 REPLIES 6
Reply
Message 1 of 7
gluckett
654 Views, 6 Replies

Object Class createmethod codes for Hatch?

Hi All, does anyone know the Create Method for Hatches using the Object Classification?

 

I know that polyline createmeth is 6 in the Object Class XML file,

but since I can't choose Hatch as a create method, I was hoping to hack it.

 

 

6 REPLIES 6
Message 2 of 7
luc.vanlinden
in reply to: gluckett

Hi

 

I had a similar issue with Mlines. you can classify them but you cannot create them.

 

This is how I tried to solve it. You can try a similar approach for your Hatch:

 

Use the XML file itself and edit it:

 

1. in the Feature tag, add to the arxclassRANGE the AcDbtype that corresponds to a create method that is supported and that you can use.

 

In my case I had: acrxclassrange="AcDbMline"

 

and changed it to:

 

acrxclassrange="AcDbMline,AcDbPolyline"

 

and then I added the following elements:

 

<CreationVersion FdoLink="1">2</CreationVersion>
<Create>
<CreateMethod>5</CreateMethod>
<StartWBlank>1</StartWBlank>
<StartWidth>0</StartWidth>
<EndWBlank>1</EndWBlank>
<EndWidth>0</EndWidth>
<Linetype>2</Linetype>
</Create>

 

This is the creation settings for a polyline.

 

This means that you can create your object via the feature classification, but will require some post processing via LISP for example. In my case I run a LISP to change that polyline into a multiline.

 

In yourcase you might want to add a closed polyline in your arxclass range with the appropriate creation method and options, and then you need a post-creation step either mannually or via some routine. To know what are the details for the creation option, you can quickly test it to classify a "closed" polyline entity. 

 

On the other hand be aware that you might be classifying features incorrectly as you allow other entitytypes to your feature class.

 

Not the cleanest way, I agree. But I do not understand that it is so hard for Autodesk to support their CAD to GIS and back in a consistent way. 

 

Soit, hoping it can help you in some direction.

 

 

Luc

 

 

 

Message 3 of 7
gluckett
in reply to: gluckett

Wow, it is too bad we have to hack so much to support DWG files, within AutoCAD Map 3D.
FDO, classification, and object data/link templates all need better integration within the product.

#eatyourowndogfood
Message 4 of 7
luc.vanlinden
in reply to: gluckett

Hi

 

I totally agree!  +5 for Autodesk to fix up a lot of these CAD to GIS use cases, if you ask me.

 

Here is a list of all the other things I recently bumped into. With an extreme lazy error trapping and vague error feedback message "export failed" it took me a long time to get to the bottom of why some of the exports did fail.

At a given moment I was looking get back to mapose support for oracle but even this is limited these days to 32bit.

 

It would be good that Adesk would spent some time on fixing and enhancing this core CAD – classify - GIS functionalities rather than just releasing new versions too quickly.

 

Any way here is the list of other issues:

 

1. Mapping to Industry model is missing Object classification as input, meaning all the effort for the Object classification definition should be redone.

 

2. No decent error messaging on mapexportFDO. Mainly just saying “Export failed”.

 

3. In the first step of the mapexportFDO the mapping definitions seems to be validated. If a mapping is incorrect (either datatype or missing target class or attribute), only the "Exportort failed" is returned. With a long list of object classes and mapping definitions, it is tedious task to find out what is actually making the export to fail.

 

4. In a second step, once the mapping is not causing any issue, the mapexportfdo is returning the message X features of X features exported. Even if non or just a subset ends up in the database (Oracle for example), it is just said exported X out of X.

If for example Oracle returns an error message and rolls back the transaction with a proper ORA error (constraint or trigger error for example), none of this is returned to the user. IT doesn’t even says something went wrong. This makes it extremely uncertain to know if the export actually succeeded or not (trustworthy mapexport). When the user finds out something is not exported correctly, when he noticed something is missing then still it is hard to find out what is actually the real cause of the failure.

 

5. With mapexport MAP will try to enforce a coordinate system transformation, even if you as a user have NOT selected the thick box to do so (on the 3rd tab of the mapexport). If you have for example a user defined Oracle SRID that MAP 3D does not understand and your workspace has a map defined CR assigned, mapepxort returns the message "export failed", why this happens, where to look for... you have to start digging around, testing etc etc, completely in the dark (but this could been also the other previous examples). Only when no cr is assigned mapexortfdo will use the table's metadata srid.

USE CASE: cad drawing georeferenced using WMS backdrop. This will automatically assign CRS. Need to unassigned cr (thanks to Oliver: (http://forums.autodesk.com/t5/AutoCAD-Map-3D/mapexportfdo-to-FDO-Oracle-with-user-defined-SRID-in-Or...)

 

 

6. With mapexport you can map more then 1 object class to the same single feature class. This is quoted in the help and is allowed in the dialog box. However if the mappings are based on different target columns, this will not be respected.

In order to get around this, I need to create key preserved views in Oracle as the target feature class, getting a 1 to 1 mapping.  (http://forums.autodesk.com/t5/AutoCAD-Map-3D/MAPEXPORT-map-more-than-one-drawing-object-to-a-single-...)

 

7. the old mapexport had the ability to apply lisp statements/functions in the source properties side. Would still be useful.

 

8. For some reason the entity property .ROTATION is not map-able to a double.in the mapexport mappings.

 

9. There seems not to exist a "classify all" command. You have to perform this in an object class per object class approach. I have used the .NET classify example and extended it.

 

10. create classify object will not create the autocad layer (if it does not exist, take new drawing attch defintion file, create object) if this is set explicitly in the object classification definition. Object data tables are properly created, strange not?

 

11. create options for object classification extended to other autocad entities

 

11. More flexible support to use bulk copy without the need for the FDO metadata tables.

 

I will stop here, just wondering if these functions are actually used and are properly tested?

The most frustrating in this is that I actually lost 7 days on a project just to figure things out due to the "export failed" or "X objects exported from X" feedback.

 

 

Luc

Message 5 of 7
norman.yuan
in reply to: luc.vanlinden

Wow, lot of things you have tracked.

 

As for Object Classification, I'd stay away from it if have not been invest a lot into using that AutoCAD Map feature.

 

It was introduced in AutoCAD Map 2006, called Feature Classification and renamed to Object Classificationin AutoCAD Map 2007, in order to not confuse AutoCAD Map user, with Autodesk move its main GIS related interest on FDO. From that point on (Acad Map 2007) the Object Classification stopped progress: it is a dead-end technology to use. IMO, even AutoCAD Map still support it. I bet Autodesk must feel regretable that they introduced something and only found out they were better off paying more effort on FDO in AutoCAD Map in next AutoCAD Map release.

 

Unless one has to support lots of drawings that have Object Classification data attached, I'd say it is better not to use Object Classification. Object data is more mature than Object Classification

 

 

Message 6 of 7
gluckett
in reply to: gluckett

Ah,FDO's war on the DWG.

I must say, its pretty nice to be able to click on a Object Classification of a hydrant and have a HYDRANT block put on the WATER_HYDRANT layer, with Object Data already attached.

Old school. Yes. DWG friendly, definitely.

Message 7 of 7
luc.vanlinden
in reply to: gluckett

Gordon you are right, but why would this be old school?

FDO feature also has a couple of limitations.

 

Autodesk could save them a lot of effort, by publishing the OD dxf structure and sponsor the OGR/GDAL team to get this working in a transparent way.

 

Man, man man, just spent today looking at the status of the MAPIMPORT.

 

  1. NO way to import data from Oracle containing the rotation of “a point symbol” in a separate column. There just does not exist a way to map this back to a block and set the blocks rotation. How much more basic CAD could  this be?
  2. Actually the mapimport only has a minimum mapping capabilities to “attribute information”. FDO (Oracle) columns can only be mapped to Object data or to a block attribute. No other cad entities props can be database-driven set. Not even the those minimum supported properties of the object classification.
  3. BTW if you are mapping to block attributes, this is only feasible if you have Object classification, else you have to ensure the source (Oracle) columns) need to have the same name of the attributes. So far the definition of “mapping attributes”
  4. As said before even the object classification will not even create the appropriate layer ?!?
  5. Had an Object classification based on a specific block (definition). When such an object was created MAP 3D ran into an endless loop of inserting endlessly instances of this block. Finally crashed or had to be killed. Again after digging around and testing and comparing other object classes based on a block, turned out that this  happens when a block is defined with the “uniform scale” box checked. So redefine block first with uniform scale unchecked.
  6. Had a look at the “preserve FDO style to acad” stuff via the save as drawing. If you choose the visual and the linetype is too complex, the feature is just skipped. I would at least expect it to exist with the most simplest rendering rather than just skipped.
  7. On the other hand here it is feasible to use a block definition as a point representation, have it rotated and even the attribute set directly to a Oracle column, great! But once save to drawing with editable (also visual) the block is exploded.
  8. The save as drawing will assign layers with  a name concatenated on FDO_USERNAME_FeatureClass name. Probably to make it unique I guess. Have given up on this not even tried using that template stuff.

 

I believe the Object classification is a very great concept just could not believe they have not developed it correctly or into more dept. It could have been a good way to facilitate all this in between and not functioning efforts for the GIS - CAD support.

 

Luc

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost