[gdal-dev] Possible error in orientation of converted arcs from dxf

Tue Feb 27 09:01:50 PST 2024

I have not worked with DXF files since the early 90s so my info might be
wrong. But check if any of your transformations are ending up with negative
start/end angles. That used to be able to reverse the direction of the arc.
Again this is old info and I don't quite understand your problem so I'm
sorry if this is noise.

On Tue, Feb 27, 2024 at 3:32 AM Jan Heckman via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Hi,
>
> I set up a case for an issue and had to conclude that this issue does not
> help in solving my problem (finding the proper vertex sequence/need to
> reverse in a series of lines and arcs).
> Surprisingly at first, in the case I made, there were arcs with proper as
> well as improper sequence which all had gone through the same procedure
> during conversion with ogr2ogr.
>
> When specifying an arc by startangle, endangle, orientation
> (counterclockwise around the positive z axis, using radius and midpoint),
> the order of the vertices cannot also be specified (differently) by the
> same ingredients.
>
> Not being very good at dxf, I looked at the optional specification of an
> extrusion vector (in an arc) in the hope that this relates to the sweep of
> the arc,
> rather than the extrusion of a plane arc to a 3D surface, why else define
> this vector in the context of an object rather than in the context of an
> extrusion command?
> I'm still unsure of the meaning of this thing. and haven't found docs to
> support the notion that the sweep might be intended.
> And even if it is, I haven't seen the codes in the dxf files I worked with
> sofar.
>
> Anyway:
> The codes are 210, 220, 230 (x,y,z) and by default 0.0,0.0,1.0. Setting
> this to 0.0,0.0,-1.0 made the arc invisible in Qgis and in the ogr2ogr
> produced shapefile.
> When I have time I'll look more into the gdal sources, but it looks like I
> need to handle this problem where it arises using my own linestring
> dissolve routine.
>
> Thanks,
> Jan
>
>
> On Sun, Feb 25, 2024 at 10:13 PM Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Please file an issue with a (as small as possible) .dxf file reproducing
>> the issue
>>
>> Even
>> Le 25/02/2024 à 22:05, Jan Heckman a écrit :
>>
>> Hi Even, all,
>> There might be a slight connection, but my case imo does not involve
>> either a bulgefactor or a smoothing routine;
>> it is the basic conversion/render of a circular arc where apparently
>> start- and endangle are interchanged sofar without apparent cause.
>> Possibly the dxf has, earlier on, something which influences (rightly or
>> wrongly) the clockwise setting/bool seen in this type of driver function.
>> So I'll first try to find any global setting in the dxf which might
>> encourage clockwise circle handling instead of default anti-clockwise.
>> As an afterthought, this cannot be the case as then the arc would have
>> been drawn in the other direction, giving a very large arc instead of a
>> smallish one.
>> As I said earlier, the correct arc is used but with the (imo) wrong
>> orientation/sequence of the vertices.
>> Jan
>>
>>
>> On Sun, Feb 25, 2024 at 2:08 PM Even Rouault <even.rouault at spatialys.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm wondering if there woulnd't be a connection with
>>> https://github.com/OSGeo/gdal/issues/1839#issuecomment-537185826 ?
>>>
>>> Even
>>>
>>> Le 25/02/2024 à 13:32, Jan Heckman via gdal-dev a écrit :
>>> > Hi all,
>>> > Sorry for a somewhat long post, but here we go:
>>> > I am converting a .dxf having a sequence of simple lines and arcs
>>> > which form a continuous (poly)line, (correctly) ordered by
>>> > EntityHandle. The arcs are converted (to shp) as well as displayed
>>> > (Qgis) in the opposite direction as the simple lines. Checking the
>>> > codes and docs, this appears wrong.
>>> > Below the minimal relevant information, I can add the complete .dxf,
>>> > but I think attached files are frowned upon?
>>> >
>>> > Docs cited:
>>> >
>>> https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-0B14D8F1-0EBA-44BF-9108-57D8CE614BC8
>>> > ARC (DXF)
>>> > The following group codes apply to arc entities.
>>> > Arc group codes
>>> > Group code Description
>>> > 100 Subclass marker (AcDbCircle)
>>> > 39 Thickness (optional; default = 0)
>>> > 10 Center point (in OCS) DXF: X value; APP: 3D point
>>> > 20, 30 DXF: Y and Z values of center point (in OCS)
>>> > 40 Radius
>>> > 100 Subclass marker (AcDbArc)
>>> > 50 Start angle
>>> > 51 End angle
>>> > 210 Extrusion direction (optional; default = 0, 0, 1) DXF: X value;
>>> > APP: 3D vector
>>> > 220, 230 DXF: Y and Z values of extrusion direction (optional)
>>> >
>>> > https://ezdxf.readthedocs.io/en/stable/tutorials/dxf_primitives.html
>>> > The arc goes always in counter-clockwise orientation around the z-axis
>>> > more precisely the extrusion vector of OCS, but this is beyond the
>>> > scope of this tutorial.
>>> >
>>> > The case (extracted, whole .dxf file available):
>>> > AcDbEntity
>>> >   8
>>> > 0000-001_09_AND1N
>>> >   6
>>> > Continuous
>>> >  62
>>> >     18
>>> > 100
>>> > AcDbCircle
>>> >  10
>>> > 130974.661837
>>> >  20
>>> > 497502.478468
>>> >  30
>>> > 0.0
>>> >  40
>>> > 7576.094430000001
>>> > 100
>>> > AcDbArc
>>> >  50
>>> > 305.5444330000001
>>> >  51
>>> > 344.795475
>>> >   0
>>> > LINE
>>> >   5
>>> > 2E
>>> > 330
>>> > 1A0
>>> > 100
>>> >
>>> > The arc is converted (.shp) and drawn (qgis) from end angle to start
>>> > angle, without a 210 code to alter default behavior, which obviously
>>> > is the other way around, noting counter clock around (positive) Z-axis.
>>> > The applicability of this convention also follows from the (correct)
>>> > position of the arc in the conversion and drawing.
>>> > Only begin- and endpoints are interchanged.
>>> >
>>> > Please advice,
>>> > Thanks in advance,
>>> > Jan
>>> >
>>> > _______________________________________________
>>> > gdal-dev mailing list
>>> > gdal-dev at lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>> --
>>> http://www.spatialys.com
>>> My software is free, but my time generally not.
>>>
>>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> _______________________________________________
> 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/20240227/4df7d436/attachment.htm>