OK, I found in the source code that *MultiPoints* are simply omitted. https://github.com/OSGeo/gdal/blob/eda0808fc20564c74b9ab3186c6bf0719ddda4e6/ogr/ogrsf_frmts/dxf/ogrdxfwriterlayer.cpp#L1229 Driver supports writing: wkbPoint, wkbLineString, wkbMultiLineString, wkbPolygon, wkbTriangle, wkbMultiPolygon, and even wkbGeometryCollection. Let the driver authors decide if it can be a feature request?
Have a good day, Michał Kowalczuk czw., 16 sty 2025 o 17:31 Michał Kowalczuk <michkowalc...@gmail.com> napisał(a): > 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@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 >> and...@aitchison.me.uk >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
