Hi all,<div><br></div><div>I would actually much prefer it if people didn't use the check geometry tool at all :-p It was never really meant to be a long-term tool (I really just created it at the time to be a quick and dirty way to find issues with shapefiles), and I know that Martin and his team have created a much better geometry checker (in C++) that is kicking around somewhere that would be much better suited to most users needs. In actual fact, there is no attempt to follow OGC standards in the ftools geometry validity tool!</div>
<div><br></div><div>@ Martin: What is the status of your geometry checking tool? Is there anyway that this might be incorporated into trunk somehow? I think it would be much better to have something a bit more compliant, stable, and with a few more of the features that have been mentioned in this thread (some of which I think Martin's tool already has).</div>
<div><br></div><div>Regards,</div><div><br></div><div>Carson</div><div><br><br><div class="gmail_quote">On 31 October 2010 14:38, <span dir="ltr"><<a href="mailto:a.furieri@lqt.it">a.furieri@lqt.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Sun, 31 Oct 2010 14:00:46 +0100, Borys Jurgiel wrote<br>
<div><div></div><div class="h5">> Hi,<br>
><br>
> In Spatialite layers, if I digitize a polygon counter-clockwise, the<br>
> ftools' geometry validity check says:<br>
><br>
> Feature $n has incorrect node ordering<br>
><br>
> Is it intentional, or a bug? It doesn't affect shapefiles.<br>
><br>
<br>
</div></div>Hi Boris,<br>
<br>
in OGC-SFS specs there is absolutely no<br>
indication at all concerning the RING's<br>
node ordering (clockwise / counterclockwise).<br>
<br>
and this makes full sense, because for OGC<br>
POLYGONs the first RING always is the EXTERIOR<br>
ring, and any other subsequent RING (if present)<br>
has to be interpreted as an INTERIOR ring.<br>
<br>
this rule is absolutely clear and unambiguous:<br>
so there is no need at all to enforce a preferred<br>
node-ordering.<br>
<br>
AFAIK the nowadays obsolescent SHP format used<br>
a completely different rule:<br>
- the exterior ring has to be clockwise<br>
- any interior ring has to be counterclockwise<br>
- rings relative ordering is not relevant<br>
<br>
So I suppose that ftools (incorrectly) checks any<br>
polygon geometry for validity following the<br>
superseded SHP-like rules.<br>
<br>
But from the SpatiaLite's own perspective this<br>
makes no sense at all, because node ordering<br>
is absolutely irrelevant in this case.<br>
<br>
bye Sandro<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Carson J. Q. Farmer<br>ISSP Doctoral Fellow<br>National Centre for Geocomputation<br>National University of Ireland, Maynooth,<br><a href="http://www.carsonfarmer.com/">http://www.carsonfarmer.com/</a><br>
</div>