DXF Import: Improvement suggestions

[TerjeWiigMathisen]

Steps to reproduce

Load a single DXF file with contours from LiDAR conversion.

Actual behaviour

Everything ends up as unsymbolized objects, must be converted manually one by one tag type.

Expected behaviour

OOM needs something similar to OCAD's .CRT files, i.e. a way to do batch conversion.

It also needs to be able to import area objects, including areas with internal holes, since this is the only way to import lakes and similar area symbol types.

Configuration

Mapper Version: 0.6.7 and 0.6.210170101 Operating System: Windows 10 Pro 64-bit terje_vegetation.zip

[dg0yt]

Thanks indeed for the test file. However, the issue is already recorded, #261.

[dg0yt]

Regarding this text file: None of the importers creates objects from this file. So even OGR seems to dislike the input. It reports:

ogrdxf_hatch.cpp, 175: error at line 18 of OpenOrienteering/Test/Tickets/#828 DXF/terje_vegetation.dxf

[TerjeWiigMathisen]

This is quite strange:

Line 18 of the file is simply the normal ENDSEC line at the end of the minimal header, my contour DXF files are encoded in exactly the same way and they work nicely:

0 SECTION 2 HEADER 9 $EXTMIN 10 545500.00 20 6540500.00 9 $EXTMAX 10 548000.00 20 6544250.00 0 ENDSEC

[dg0yt]

I'm not sure what is counted as "line 18" by OGR - maybe the beginning of the offending entity. Even DWG TrueView 2014 didn't like the file. It reported line 34 IIRC.

The OGR source code is here:

OGRErr OGRDXFLayer::CollectBoundaryPath( OGRGeometryCollection *poGC )

{
    int  nCode;
    char szLineBuf[257];

/* -------------------------------------------------------------------- */
/*      Read the boundary path type.                                    */
/* -------------------------------------------------------------------- */
    nCode = poDS->ReadValue(szLineBuf,sizeof(szLineBuf));
    if( nCode != 92 )
    {
        DXF_LAYER_READER_ERROR();
        return OGRERR_FAILURE;
    }
...

So it is complaining because there is no code 92 (boundary path type flag). What we have is

...
                *** ENTITY DATA***
  0     - Entity type
HATCH
 5      - Handle
27
100     - Subclass marker
AcDbEntity
  8     - Layer name
403_yellow
100     - Subclass marker - again ???
AcDbEntity
                *** HATCH (OR MPOLYGON) DATA ***
  2     - Hatch pattern name
SOLID
 70     - Solid fill flag
1
 91     - Number of boundary paths (loops)
2
 73     - For MPolygon, boundary annotation flag
1
                *** BOUNDARY PATH DATA ***
 93     - Number of edges in this boundary path
122
                 *** POINTS X/Y ***
10
545750.00
20
6542672.00
...

So probably this is indeed invalid DXF, it just happens to work in the OCAD implementation.

[TerjeWiigMathisen]

Thanks for the investigation, I will try to come up with a DXF implementation that is according to spec and allows clean imports in both OCAD and OOM. This means using the development versions of OOM, right?

The way I wrote my code was simply to emulate what OCAD generates when you export to DXF, i.e. I did not use Autocad's original docs as my primary source.

[dg0yt]

All right, just try to test with other implementations. Apart from the free viewer from AutoCAD, most vector graphics software can read DXF. My system suggested LibreOffice Draw as well, but you can guess what the result was...

By the way OGR gives us the ability to import style information from DXF. One of my test files looks really great...

[dg0yt]

The original file was invalid.