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

Tue Feb 27 01:31:47 PST 2024

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240227/9c056f19/attachment.htm>