[Qgis-developer] ftools geometry check

[Carson Farmer]

Hi all,

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!

@ 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).

Regards,

Carson


On 31 October 2010 14:38, <a.furieri at lqt.it> wrote:

> On Sun, 31 Oct 2010 14:00:46 +0100, Borys Jurgiel wrote
> > Hi,
> >
> > In Spatialite layers, if I digitize a polygon counter-clockwise, the
> > ftools' geometry validity check says:
> >
> > Feature $n has incorrect node ordering
> >
> > Is it intentional, or a bug? It doesn't affect shapefiles.
> >
>
> Hi Boris,
>
> in OGC-SFS specs there is absolutely no
> indication at all concerning the RING's
> node ordering (clockwise / counterclockwise).
>
> and this makes full sense, because for OGC
> POLYGONs the first RING always is the EXTERIOR
> ring, and any other subsequent RING (if present)
> has to be interpreted as an INTERIOR ring.
>
> this rule is absolutely clear and unambiguous:
> so there is no need at all to enforce a preferred
> node-ordering.
>
> AFAIK the nowadays obsolescent SHP format used
> a completely different rule:
> - the exterior ring has to be clockwise
> - any interior ring has to be counterclockwise
> - rings relative ordering is not relevant
>
> So I suppose that ftools (incorrectly) checks any
> polygon geometry for validity following the
> superseded SHP-like rules.
>
> But from the SpatiaLite's own perspective this
> makes no sense at all, because node ordering
> is absolutely irrelevant in this case.
>
> bye Sandro
>
>


-- 
Carson J. Q. Farmer
ISSP Doctoral Fellow
National Centre for Geocomputation
National University of Ireland, Maynooth,
http://www.carsonfarmer.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20101031/c837c24a/attachment.html