<div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 27, 2024 at 3:32 AM Jan Heckman via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>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).</div><div>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.</div><div>
<div><br></div><div>When specifying an arc by startangle, endangle, orientation (counterclockwise around the positive z axis, using radius
and midpoint),</div><div>the order of the vertices cannot also be specified (differently) by the same ingredients.</div><div><br></div>
</div><div>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,</div><div>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?</div><div>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.</div><div>And even if it is, I haven't seen the codes in the dxf files I worked with sofar.<br></div><div><br></div><div>Anyway:<br></div><div>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.<br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Jan<br></div><div><div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 25, 2024 at 10:13 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Please file an issue with a (as small as possible) .dxf file
reproducing the issue<br>
</p>
<p>Even<br>
</p>
<div>Le 25/02/2024 à 22:05, Jan Heckman a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi Even, all,</div>
<div>There might be a slight connection, but my case imo does
not involve either a bulgefactor or a smoothing routine;</div>
<div>it is the basic conversion/render of a circular arc where
apparently start- and endangle are interchanged sofar without
apparent cause.</div>
<div>Possibly the dxf has, earlier on, something which
influences (rightly or wrongly) the clockwise setting/bool
seen in this type of driver function.</div>
<div>So I'll first try to find any global setting in the dxf
which might encourage clockwise circle handling instead of
default anti-clockwise.</div>
<div>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.</div>
<div>As I said earlier, the correct arc is used but with the
(imo) wrong orientation/sequence of the vertices.</div>
<div>Jan<br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Feb 25, 2024 at
2:08 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I'm wondering if there woulnd't be a connection with <br>
<a href="https://github.com/OSGeo/gdal/issues/1839#issuecomment-537185826" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/issues/1839#issuecomment-537185826</a>
?<br>
<br>
Even<br>
<br>
Le 25/02/2024 à 13:32, Jan Heckman via gdal-dev a écrit :<br>
> Hi all,<br>
> Sorry for a somewhat long post, but here we go:<br>
> I am converting a .dxf having a sequence of simple lines
and arcs <br>
> which form a continuous (poly)line, (correctly) ordered
by <br>
> EntityHandle. The arcs are converted (to shp) as well as
displayed <br>
> (Qgis) in the opposite direction as the simple lines.
Checking the <br>
> codes and docs, this appears wrong.<br>
> Below the minimal relevant information, I can add the
complete .dxf, <br>
> but I think attached files are frowned upon?<br>
><br>
> Docs cited:<br>
> <a href="https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-0B14D8F1-0EBA-44BF-9108-57D8CE614BC8" rel="noreferrer" target="_blank">https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-0B14D8F1-0EBA-44BF-9108-57D8CE614BC8</a><br>
> ARC (DXF)<br>
> The following group codes apply to arc entities.<br>
> Arc group codes<br>
> Group code Description<br>
> 100 Subclass marker (AcDbCircle)<br>
> 39 Thickness (optional; default = 0)<br>
> 10 Center point (in OCS) DXF: X value; APP: 3D point<br>
> 20, 30 DXF: Y and Z values of center point (in OCS)<br>
> 40 Radius<br>
> 100 Subclass marker (AcDbArc)<br>
> 50 Start angle<br>
> 51 End angle<br>
> 210 Extrusion direction (optional; default = 0, 0, 1)
DXF: X value; <br>
> APP: 3D vector<br>
> 220, 230 DXF: Y and Z values of extrusion direction
(optional)<br>
><br>
> <a href="https://ezdxf.readthedocs.io/en/stable/tutorials/dxf_primitives.html" rel="noreferrer" target="_blank">https://ezdxf.readthedocs.io/en/stable/tutorials/dxf_primitives.html</a><br>
> The arc goes always in counter-clockwise orientation
around the z-axis <br>
> more precisely the extrusion vector of OCS, but this is
beyond the <br>
> scope of this tutorial.<br>
><br>
> The case (extracted, whole .dxf file available):<br>
> AcDbEntity<br>
> 8<br>
> 0000-001_09_AND1N<br>
> 6<br>
> Continuous<br>
> 62<br>
> 18<br>
> 100<br>
> AcDbCircle<br>
> 10<br>
> 130974.661837<br>
> 20<br>
> 497502.478468<br>
> 30<br>
> 0.0<br>
> 40<br>
> 7576.094430000001<br>
> 100<br>
> AcDbArc<br>
> 50<br>
> 305.5444330000001<br>
> 51<br>
> 344.795475<br>
> 0<br>
> LINE<br>
> 5<br>
> 2E<br>
> 330<br>
> 1A0<br>
> 100<br>
><br>
> The arc is converted (.shp) and drawn (qgis) from end
angle to start <br>
> angle, without a 210 code to alter default behavior,
which obviously <br>
> is the other way around, noting counter clock around
(positive) Z-axis.<br>
> The applicability of this convention also follows from
the (correct) <br>
> position of the arc in the conversion and drawing.<br>
> Only begin- and endpoints are interchanged.<br>
><br>
> Please advice,<br>
> Thanks in advance,<br>
> Jan<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote>
</div>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>