[gdal-dev] DXF MLTIPOINT

[Michał Kowalczuk]

Dear Andrew,
are you a CAD user?

DXF does not support MultiPolylines (MultiLineString) natively. Lines and
MultiLines are both saved as LWPOLYLINE objects. It means that Multilines
are exploded.
Below you can find the DXF definition of 3 separate LWPOLYLINES that
originally in GIS creates a MultiPolyline with 3 parts.
*GIS:*

*MultiLineStringZ ((551570.21572770935017616 658393.32015316328033805 0,
603420.7277320041321218 670468.09692128677852452
0),(562934.71150947257410735 634954.04760327667463571 0,
595607.63688204193022102 644897.98141231946647167
0),(571458.0833457950502634 616486.74195791140664369 0,
611233.81858196633402258 625010.11379423388279974 0))).*
*CAD:*







































































*LWPOLYLINE  520001100AcDbEntity  8multiline // mycomment - this is only a
name of my layer, not the name of the
object!100AcDbPolyline 700 902 380 10551570.215727709
20658393.320153163 10603420.727732004 20670468.096921287
0LWPOLYLINE  520002100AcDbEntity
8multiline100AcDbPolyline 700 902 380 10562934.711509473
20634954.047603277 10595607.636882042 20644897.981412319
0LWPOLYLINE  520003100AcDbEntity
8multiline100AcDbPolyline 700 902 380 10571458.083345795
20616486.741957911 10611233.818581966 20625010.113794234
0*

If you convert "normal" polyline it also will be saved in DXF as LWPOLYLINE:





















*LWPOLYLINE  520001100AcDbEntity
8lines100AcDbPolyline 700 902 10476764.880499188 20719473.283908963
10637413.384866117 20487307.112886079
0*

The same with polygons/multipolygons - the both are converted to
non-multiple native CAD object "HATCH".
I will not copy the definition from DXF here. It can be easily verified.

It leads to conclusion that in both cases: MultiLines and MultipPolygons
are exploded before writing to native CAD objects...
Please also show me where can I find confirmation of the following
statement:



*As I read the DXF 2014
spechttp://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf
<http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf>the
underlying issue is that the DXF format supports
MultiPolylinesMultiPolygons but not MultiPoint.*

All the best!
Michał Kowalczuk

czw., 16 sty 2025 o 14:37 Andrew C Aitchison via gdal-dev <
gdal-dev at lists.osgeo.org> napisał(a):

> On Thu, 16 Jan 2025, Michał Kowalczuk via gdal-dev wrote:
>
> > Thank you, Jukka.
> > I saw this post. The main question is why the DXF driver implementation
> can
> > explode MultiPolylines and MultiPolygons (which is more complex) and
> > MultiPoint *not*?
>
> As I read the DXF 2014 spec
>
> http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf
> the underlying issue is that the DXF format supports MultiPolylines
> MultiPolygons but not MultiPoint.
> Thus the driver does not need to explode MultiPolylines and MultiPolygons
> and, like the FME writer, would need to do something new and extra
> to explode a MultiPoint and include the points in the DXF.
>
> Alan Thomas says in
>
> https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/dxf/KNOWN_ISSUES.md
> that
>      The writer does not write out ATTRIB entities for a POINT feature
> with
> a non-empty BlockAttributes field, that is to say, block attributes are
> not round-tripped. This is certainly a gap in the feature set, but I only
> plan to write this code if someone expresses a need for it.
>
> I speculate that this is related ...
>
> --
> Andrew C. Aitchison                      Kendal, UK
>                     andrew at aitchison.me.uk
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250116/4a696e2d/attachment-0001.htm>