Hi Stefan, Thanks for your comments.
- first of all, I'm curious why you chose to use one traits class for each "agnosticism". this differs from the standard library, so I guess there is a specific reason for it?
Yes. It was discussed on the Boost List before. We're conforming to MPL conventions here, so creating meta-functions, name things "type", etc. We didn't want to create one blob trait.
- is there a default implementation of the traits classes? I haven't found one in code/coordinate_dimension. this would simplify writing concept models in many cases, especially with 5 different traits for a Point.
But there are registration macro's. They support different use cases. So most people will not have problems adapting their classes to the concepts. For points we've no default. For linestring we have (you can override push_back). For polygon the clockwise orientation is default.
- on a minor note, tag<> seems a little non-descriptive, compared to iterator_category in the STL.
It is mainly for internal usage. It is the base for "tag dispatching" so we thought that tag was appropriate. "geometry_category" could indeed be an alternative but that never came up in our minds. And it is a little long.
Boost.Iostreams and Boost.PropertyMap both use "category", which might also be suitable for GGI, since it has its own namespace and there are no other categories I assume.
Yes, category is also an alternative and there are no other categories. But it still is "tag dispatching" so if no one has big problems with tag, I prefer to leave it like it is now. Library users will not have to use it, unless they're implementing algorithms, or adapting geometries without using macro's. Regards, Barend