Geometry Boost List: Re: [geometry] Reliable invariants of geometry representation? Validation tests?

Subject: Re: [geometry] Reliable invariants of geometry representation? Validation tests?
From: Volker Schöch (vschoech_at_[hidden])
Date: 2012-02-10 12:06:29

Hi Barend,

> The rules can the best looked up in this OGC document (Simple Features - Common Architecture)
> http://portal.opengeospatial.org/files/?artifact_id=25355

This was exactly the pointer I was looking for. Thank you!

> Besides the combinatorial explosion we already have (geometry types, point types, dimensions) this gives various extra combinations. There are many tests in the unit test which test both orientations, and open/closed. I have to inventarise again if it is complete with that respect.

<opinion>
That's hell, obviously. Is this really required? I for one would be fine if only combinations of polygons with the same orientation/closedness were supported. I'd expect that in any application domain, you'd usually agree on one representation for your application. If someone needs to combine with other representations, these could be easily converted before applying any algorithms. The reverse() algorithm is already there to help with changing orientation, and appending or removing a begin==end is trivial. You definitely should support these different representations, but I don't see a point in supporting all combinations thereof.
</opinion>

> > > > [...] why did you choose to require closed polygons having begin==end?
> > > It is not required. This is optional either. Opened/closed. Most (probably all) algorithms are checked on this.
> > Huh. Can you elaborate? Correct me if I'm wrong: Are you saying that begin==end is "optional", i.e., that all algorithms should return the same results, with the same big-O performance, whether or not begin==end, assuming that the polygon type is templated as Closed=true?
> Yes. We have one iterator type (closing_iterator / closeable_view) which closes the polygon. All algorithms assume closed polygons. But the input can be open and it is then closed automatically by the iterator. This is all compile time. There is no "if"...

Thank you for your patience, I finally understand. I didn't get it at first because I kept inverting the meaning of Closed=true and Closed=false in my mind. I don't know why and I agree that it makes sense the way it is.

Looking forward to boost 1.49! :-)
   Volker

--
Volker Schöch | vschoech_at_[hidden]
Senior Software Engineer
think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany
http://www.think-cell.com | phone [phone] | US phone [phone]
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl