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@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.roua...@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.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. >>> >>> -- 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 >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
