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.
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
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
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
Norman Yuan
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.
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.
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.