Geometry Boost List: [ggl] Ring type as template parameter for polygon

Subject: [ggl] Ring type as template parameter for polygon
From: Tarem, Zvi (zvi.tarem)
Date: 2011-11-20 16:16:39

I totally agree regarding the uncontrolled proliferation of macros.

As for consistency, consider this:
->A coordinate type lays underneath the entire object structure.
->A point is a basic building block that depends on the coordinate type.
->boxes, linestrings and rings are all a collection of points, so they
  naturally depend on their element type - the point type.
->polygons are a collection of rings, existing only to allow the
  specification of holes. All other 'polygon-like' attributes are
  associated with rings, so they should naturally depend on their
  element type - the ring type.
->multi_polygons are a collection of polygons, so they naturally depend
  on their element type - the polygon type.

I fail to see the advantage in the dependency of polygons on the point
type, even for consistency.

Note that if the polygon template depends on the ring type, then no custom
polygon type is required for a custom ring type, a simple typedef will suffice.

Perhaps in my spare time(?) I will try to implement a ring-dependent
polygon type and see where it leads.

Regards,

Zvi
 
From: ggl-bounces_at_[hidden] [mailto:ggl-bounces_at_[hidden]] On Behalf Of Barend Gehrels
Sent: Sunday, November 20, 2011 17:04
To: Generic Geometry Library Discussion
Subject: Re: [ggl] Ring type as template parameter for polygon

Hi Zvi,

On 20-11-2011 14:42, Tarem, Zvi wrote: 
Currently, the polygon template depends on the point type. But the only data members of a polygon are rings, not points. So in my opinion, the polygon template should depend on the ring type (which will, of course, imply a point type).
?
Currently, every time you create a custom ring type (which is easy using the registration macros), you are required to create a corresponding custom polygon type (without the convenience of a registration macro). This is an unnecessary burden on the user of the library.

Yes, that could have been done as well. All (non-multi) geometries are based on the Point parameter, so that makes them consistent.

The boost::geometry::model::polygon is one of the provided geometries, but you can also use other or create your own. So you can create a version based on rings.

About the convenience of registration macro's for polygons, we discussed about that a week ago so I paste here a piece for convenience:

We were, in general, a little hesitant, we want to avoid creating dozens of macros. The more complex the geometry type is, the more possibilities there are. For that reason we did not provide them for polygons. Users can specialize themselves, so there is never a problem. 

Regards, Barend

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.