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

[Even Rouault]

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/20240225/06d5e861/attachment.htm>