<div dir="ltr"><div dir="ltr">Dear Andrew,</div><div dir="ltr"><div>are you a CAD user?</div><div><br></div><div>DXF does not support MultiPolylines (MultiLineString) natively. Lines and MultiLines are both saved as LWPOLYLINE objects. It means that Multilines are exploded.</div><div>Below you can find the DXF definition of 3 separate LWPOLYLINES that originally in GIS creates a MultiPolyline with 3 parts.</div><div><u>GIS:</u></div><div><i>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))).<br></i></div><div><u>CAD:</u></div><div><i><b>LWPOLYLINE</b><br> 5<br>20001<br>100<br>AcDbEntity<br> 8<br>multiline // mycomment - this is only a name of my layer, not the name of the object!<br>100<br>AcDbPolyline<br> 70<br>0<br> 90<br>2<br> 38<br>0<br> 10<br>551570.215727709<br> 20<br>658393.320153163<br> 10<br>603420.727732004<br> 20<br>670468.096921287<br> 0<br><b>LWPOLYLINE<br></b> 5<br>20002<br>100<br>AcDbEntity<br> 8<br>multiline<br>100<br>AcDbPolyline<br> 70<br>0<br> 90<br>2<br> 38<br>0<br> 10<br>562934.711509473<br> 20<br>634954.047603277<br> 10<br>595607.636882042<br> 20<br>644897.981412319<br> 0<br><b>LWPOLYLINE<br></b> 5<br>20003<br>100<br>AcDbEntity<br> 8<br>multiline<br>100<br>AcDbPolyline<br> 70<br>0<br> 90<br>2<br> 38<br>0<br> 10<br>571458.083345795<br> 20<br>616486.741957911<br> 10<br>611233.818581966<br> 20<br>625010.113794234<br><b> </b>0</i><br></div></div><div><br></div><div>If you convert "normal" polyline it also will be saved in DXF as LWPOLYLINE:</div><div><i><b>LWPOLYLINE</b><br> 5<br>20001<br>100<br>AcDbEntity<br> 8<br>lines<br>100<br>AcDbPolyline<br> 70<br>0<br> 90<br>2<br> 10<br>476764.880499188<br> 20<br>719473.283908963<br> 10<br>637413.384866117<br> 20<br>487307.112886079<br> 0</i><br></div><div><br></div><div>The same with polygons/multipolygons - the both are converted to non-multiple native CAD object "HATCH".</div><div>I will not copy the definition from DXF here. It can be easily verified.</div><div><br></div><div>It leads to conclusion that in both cases: MultiLines and MultipPolygons are exploded before writing to native CAD objects...</div><div>Please also show me where can I find confirmation of the following statement:</div><div><i><font color="#3d85c6">As I read the DXF 2014 spec<br><a href="http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf" rel="noreferrer" target="_blank">http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf</a><br>the underlying issue is that the DXF format supports MultiPolylines<br>MultiPolygons but not MultiPoint.</font></i></div><div><br></div><div>All the best!</div><div>Michał Kowalczuk</div><div><br></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">czw., 16 sty 2025 o 14:37 Andrew C Aitchison via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 16 Jan 2025, Michał Kowalczuk via gdal-dev wrote:<br>
<br>
> Thank you, Jukka.<br>
> I saw this post. The main question is why the DXF driver implementation can<br>
> explode MultiPolylines and MultiPolygons (which is more complex) and<br>
> MultiPoint *not*?<br>
<br>
As I read the DXF 2014 spec<br>
<a href="http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf" rel="noreferrer" target="_blank">http://images.autodesk.com/adsk/files/autocad_2014_pdf_dxf_reference_enu.pdf</a><br>
the underlying issue is that the DXF format supports MultiPolylines <br>
MultiPolygons but not MultiPoint.<br>
Thus the driver does not need to explode MultiPolylines and MultiPolygons<br>
and, like the FME writer, would need to do something new and extra<br>
to explode a MultiPoint and include the points in the DXF.<br>
<br>
Alan Thomas says in<br>
<a href="https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/dxf/KNOWN_ISSUES.md" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/dxf/KNOWN_ISSUES.md</a><br>
that<br>
The writer does not write out ATTRIB entities for a POINT feature with <br>
a non-empty BlockAttributes field, that is to say, block attributes are <br>
not round-tripped. This is certainly a gap in the feature set, but I only <br>
plan to write this code if someone expresses a need for it.<br>
<br>
I speculate that this is related ...<br>
<br>
-- <br>
Andrew C. Aitchison Kendal, UK<br>
<a href="mailto:andrew@aitchison.me.uk" target="_blank">andrew@aitchison.me.uk</a>_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div></div>