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
