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.roua...@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@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not. > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
