#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 |
Cc: |
Description
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)
Change History (6)
by , 13 years ago
Attachment: | uster_dxf_writer_tests.zip added |
---|
comment:1 by , 13 years ago
Component: | default → OGR_SF |
---|---|
Keywords: | DXF added |
Status: | new → assigned |
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 , 13 years ago
comment:3 by , 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 , 13 years ago
Milestone: | → 1.8.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
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 ogr_dxf.py test script (r21074).
Let me know if you encounter any more compatibility problems.
comment:5 by , 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!
Andreas
zip file contains postgis table dump and header file used during conversion