Nice. Just a few in-line comments.

BTW in SVG the elements are named currently like this:
default:
<g id="product-product-0b74b3fa-1a92-405e-9ac9-d59067be1d42-body">
--use-element-names:
<g id="product-A102">
--use-element-guids:
<g id="product-0BTBFw6f90Nfh9rP1dlXr2">

Was thinking that maybe the "product" prefix could be dropped in order to have consistent naming in all formats?

Well, I assume nobody really cares, but XML identifiers are not supposed to start with a number [1]. This is the reason for the product- prefix. I guess the same applies to collada, as most names and ids are of type xsd:NCName. Therefore I would propose to have some sort of prefix in collada and svg output.

[1] http://www.datypic.com/sc/xsd/t-xsd_ID.html

I see, in that case some kind of prefix could be justified for XML output's sake.

BTW was thinking to change the default behavior of overwriting output file always to fail instead and having a --overwrite switch or something as I've got bitten by this couple times in the past when working with large files that could take up to 30 minutes to convert (convert, try new options for a different vesion, but forget to change output filename and the just converted file is nuked instantly). Alternatively, some kind of temporary file would work too. How does this sound to you?

1. I think a temporary file is a good idea regardless, upon completion this would then be moved. Moving a file is an atomic operation, so any process checking the existence of the file knows that if it exists the process has finished and the entire file can be read.

2. As for overwriting, I can see where this would be annoying. An alternative would be a prompt that you can silence with -y. I think this is more common at least in the linux world. Besides, you also have to consider users that simply drag a file over the executable in order to convert it. The console would disappear immediately so they cannot read what had been going on.

Aye, prompt sounds good.

Just a status update: I have been looking into writing UVs for OBJ which turned out to be not 100% trivial task on my spare time but I should able to figure out by looking some existing exporters for pointers.

Ok, let me know where I can assist.

OK. Could you give a few pointers how you would like the scene bounding box to be precomputed? Should this occur in IfcGeom::Iterator::initialize()?

I think that would be a good place. Question also is what products to include. If only including products that will be emitted, you have the risk of users processing types separately being unable to overlay their models geometrically. So, I'm guessing something like this would work:

            double minx = std::numeric_limits<double>::infinity();
            ...
            IfcSchema::IfcProduct::list::ptr products = ifc_file->entitiesByType<IfcSchema::IfcProduct>();
            for (IfcSchema::IfcProduct::list::it it = products->begin(); it != products->end(); ++it) {
                IfcSchema::IfcProduct* product = *it;
                if (product->hasObjectPlacement) {
                    // This is a bit buggy, but it's important that the trsf is newly initialized every time, or they will be concatenated (and wrongly stored in the cache!).
                    gp_Trsf trsf;
                    if (kernel.convert(product->ObjectPlacement(), trsf)) {
                        const gp_XYZ& position = trsf.TranslationPart();
                        minx = (std::min)(minx, position.X());
                        ...
                    }
                }
            }

Is it possible to get a reliable IfcBoundingBox for a product?

Some models contain explicit BoundingBox representations for products. For most other representations it can potentially be straightforward to compute them, without too much computation, except for things like boolean operands where computing the boundingbox is basically equivalent to the actual geometry processing.

If the goal is mostly to workaround issues like #8 and maximizing floating point precision it shouldn't really matter whether to use the bounding box or placement origin. Most of these cases come from a very large translation at the IfcSite or IfcBuilding level. For example in the case of #8 . If this offset would be introduced within the geometries the model would be seriously flawed.

#1421= IFCCARTESIANPOINT((114502766.318516,1185944009.,0.));
#1423= IFCDIRECTION((0.995788774458495,0.0916772417912352,0.));
#1425= IFCAXIS2PLACEMENT3D(#1421,#19,#1423);
#1426= IFCLOCALPLACEMENT($,#1425);
#1427= IFCSITE('3o91zj$Gr6cQ_i1EP5O_03',#41,'0214 41 1 00',$,'',#1426,$,'14323',.ELEMENT.,(59,39,52,987060),(10,47,40,726547),62050.,'0214 41 1 00',$);

From that point of view an alternative way of alleviating this problem would be an option to ignore Site and Building-level placements. That is also quickly to implement and might even work more predictably to users.

fyi, I am also opening a pull request #47. I will wait with merging as our PRs will conflict.

It contains some performance improvements that I guess are also of interest to you. Most notably in collada files, geometrical instances (IfcMappedItems) can now re-use the same geometry definition. Also, it seems that this caching is not doing us any good. Would appreciate a second eye testing this.

Great, those improvements sound good for us. This PR should be now ready to go.

Or, I could try squeezing in the --yes/-y switch and/or temporary output file if we're not in a hurry.

Added usage of temporary file and file overwrite switch. Let me know what you think.

This can be merged, if deemed OK. However, I also started looking into "include/exclude with children" functionality as an acute need emerged for that (complex model with many buildings but I only need geometry for one or two storeys and without --weld-vertices (I'm using --generate-uvs) he DAE is too big (almost 500 MB) for importers).

If you don't mind I would like to go ahead and merge. Please create a new PR when ready. Thanks for your great work.

PS: Don't forget to test the file on my feature branch #47 as I'm sure the geometry instancing will cut a great deal from your DAE file.

OK, great. I already have a working version of --with-children switch (e.g. --include --with-children --names "Level 1") and I'll provide a PR of this after some testing. Is the name OK or should it be more longer/descriptive? I'm also open for suggestion for enhancing the file overwrite feature (maybe ask for new file name if the file already exists etc.).

I'll provide a PR of this after some testing. Is the name OK or should it be more longer/descriptive?

Sounds good. I think it's descriptive enough. I'm not sure at this point what is easier to implement in terms of --include-with-children or --include --with-children. The latter would need additional precautions to make sure --with-children is not specified by itself. I can live with both. Perhaps we are stretching what can be reasonably accomplished with boost::program_options and we almost need some sort of grammar what is a valid command line.

I'm also open for suggestion for enhancing the file overwrite feature (maybe ask for new file name if the file already exists etc.)

I am fine with the way it is, but am also open to changing it.

One last remark, if you try the feature branch mentioned above, be sure to checkout 59d2d227d9a13b352f20367a20572ed74fe0bf0d, as after the merge it still broken as mentioned in #47 (comment)

I'm quite busy with a project but I should have some time for testing on Thursday.