[gdal-dev] DXF MLTIPOINT

[Michał Kowalczuk]

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 <michkowalczuk at 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 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/20250117/a878cf43/attachment.htm>