Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#3820 closed defect (fixed)

dxf generated by ogr crashes Autodesk

Reported by: neumann Owned by: warmerdam
Priority: high Milestone: 1.8.0
Component: OGR_SF Version: unspecified
Severity: major Keywords: DXF


potentially related to header.dxf file, blocks or layer handling

dxf was generated by this command:

ogr2ogr -f DXF test_ogr.dxf -dsco header=header_export_werkplan_abwasser.dxf -spat 695700 245900 696000 246100 PG:"dbname='uster' host='server' port='5432' user='www' password='pw' schemas=abwasser tables=abwasser.export_dxf_geo405(the_geom)"

The FME viewer also displays a fatal error. Autodesk crashes during loading of file.

Attachments (1) (170.8 KB ) - added by neumann 13 years ago.
zip file contains postgis table dump and header file used during conversion

Download all attachments as: .zip

Change History (6)

by neumann, 13 years ago

Attachment: added

zip file contains postgis table dump and header file used during conversion

comment:1 by warmerdam, 13 years ago

Component: defaultOGR_SF
Keywords: DXF added
Status: newassigned

I have reproduced problems reading the generated file in Autodesk Volio View. I'm investigating further.

I will note that it is quite dangerous to use a custom header with the generic trailer file due to the risk of conflicting entity ids. It might be prudent to also use -dsco trailer=header_export_werkplan_abwasser.dxf. However, I have determined this doesn't solve the problem with Volio View.

comment:2 by warmerdam, 13 years ago

I have implemented several fixes (r21071) which fix subsets of the features but a full dump of the whole table is still failing with VolioView - I'll have to continue digging tomorrow.

comment:3 by warmerdam, 13 years ago

I have come to the conclusion part of the problem is the $HANDSEED variable in the header. It appears this should be the next available entity id (in hex as usual). In the provided header it is 737 and if I write an entity with ID 738 then the file will not import. It appears while loading the file some new entities are created by the application starting with HANDSEED, and if these conflict with existing entities the import will fail, or in one case I saw a hard crash of Volio View.

It appears I will need to have a way to set HANDSEED properly when writing the file rather than using the value from the seed file trustingly.

comment:4 by warmerdam, 13 years ago

Milestone: 1.8.0
Resolution: fixed
Status: assignedclosed

OK, it turns out some apps (ie. Volio View) are very sensitive to extra whitespace after the value of the $HANDSEED variable, but I seem to have something working well now. It is in trunk (r21075) and I've updated the test script (r21074).

Let me know if you encounter any more compatibility problems.

comment:5 by neumann, 13 years ago

Thank you - I will test tomorrow when I am back to work. If you see a better solution for providing block definitions, other than using a header.dxf, please let me know.

But maybe the problems are gone now with the new version.

Thanks so far!


Note: See TracTickets for help on using tickets.