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

[Jan Heckman]

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