Ideally I'd like to see Iterator refactored a bit more. It currently reminds a bit of Java-style iterators, but is lacking certain things. I think something like this would be nice:

No filtering:

IfcGeom::Iterator it(...);
while(it.has_next()) {
    // next() renamed to create_next() here to imply it does work and is not simply a getter
    auto geom = it.create_next();
    // write geom
}

Filtering:

IfcGeom::Iterator it(...);
while(it.has_next()) {
    auto next_prod = it.peek_next_product();
    if (filter_matches(next_prod)) {
        auto geom = it.create_next();
        // write geom
    } else {
        it.skip_next();
    }
}

While still at it, I could also throw in specifying the ID usage of serialized element (Unique ID or any of the currently supported inclusion/exclusion argument names (GlobalId, Name, Description, Tag), https://sourceforge.net/p/ifcopenshell/discussion/1782717/thread/0ff477aa/#70f4

While I quite like your suggestion, how about making it more STL-like? (We should also really then consider renaming it to something else than iterator.)

IfcGeom::Iterator model(...);
auto filtered_model = ...;
for(auto it = filtered_model.begin(); it != filtered_model.end(); ++it) {
    auto geom = *it; // <- when dereferenced the geometry is interpreted? Is that too unconventional?
}

// range based for also fine of course

// or

for(auto it = model.begin(); it != model.end(); next_matching(filters, it)) {
    auto geom = *it;
}

// And then perhaps sth like:

ColladaSerializer s(...);
std::copy(model.begin(), model.end(), s.begin());

Not sure really, just thinking out loud. For example, would it be nice to std::sort() the geometries at some point? Or perhaps we can implement the filters by means of boost::adaptors::filtered. Or should we implement this triangulation using std::transform()? Just a feeling that if we keep calling this iterator it better matches with the conception that C++ programmers have of iterators.

While still at it, I could also throw in specifying the ID usage of serialized element (Unique ID or any of the currently supported inclusion/exclusion argument names (GlobalId, Name, Description, Tag), https://sourceforge.net/p/ifcopenshell/discussion/1782717/thread/0ff477aa/#70f4

Yeah, sorry, I mixed up things in my head when typing that reply, I implied that that was already being worked on. I'm inclined to say let's first factor out this IfcLateBoundEntity before creating more dependencies on it, but maybe that's not really a consideration.

I think everything is nicely thought out, but one thing was surprising to me

1. I tried first to filter out internal elements:
   IfcConvert Duplex_A_20110907_optimized.ifc --exclude=arg Name "*Interior*"
2. This worked well, but left some floating doors from the internal walls, so, I added a --traverse.
   
   The surprising thing is that this is also applied to the default entity filter and all windows and doors disappear as they are considered children of IfcOpeningElement.

I don't see an immediately obvious solution to this, besides perhaps applying --traverse only to filters specified by users on the command line. A sec IfcConvert Duplex_A_20110907_optimized.ifc --traverse also doesn't make a lot of sense to me and the result is also counter intuitive.

Or, how about this, add a plus sign (or asterisks, but then what about shell completion) when filters need to traverse, so: IfcConvert Duplex_A_20110907_optimized.ifc --exclude=arg+ Name "*Interior*"? Thoughts? Would that be a major effort to implement?

Yeah, that was surprising also to me, at first I even thought it was a bug in my code! Let me ponder for a minute what would be the most convenient way for specifying traversal on a per filter basis, it really comes down simply to boost::program_options parsing and handling as the per filter traversal code is already possible.

Maybe --include+ and --exclude+ would be convenient to specify traversal on filter basis, but arg+, layers+, and entities+ should work as fine. The latter might be faster to implement.

OK! I Should be good to go. I think I'm going to postpone the work with specifying "arbitrary" element ID for now.

Couple more minor commits incoming if you don't mind.

Oh, and regarding your iterator ideas, those look quite good too, I especially like the look of for(auto it = model.begin(); it != model.end(); next_matching(filters, it)), let's discuss these in more detail in a separate issue.

One more pending thing: I just found out that IfcConvert crashes (null ptr access in TokenFunc::asStringRef) when trying to read an empty IFC file, so I'll see if that's easy to fix quickly.

OK, cleanup up the the fix.

Works well, many thanks. There are some small things in the ifcconvert help text that needs updating, I will commit that right way.