Logic behind depreciating 'dimension' related IFC entities. about ifc4-cv HOT 10 CLOSED

Here's the related issue on Jira:
http://jira.buildingsmart.org/browse/IFC-2678

from ifc4-cv.

If I recall, the rationale for removing was based on:

1. Focus IFC to a more narrow subset to make it easier to implement (cut out parts of the spec that are rarely used, so there's less documentation to go through).
2. Nobody implemented it to anyone's knowledge at the time.
3. Dimensioning only worked within the representation of a specific element (not associating across elements).
4. Efforts to support associative dimensioning would be better directed towards improving the more commonly used parts of the schema.

The dimensioning entities supported indicating dimensions for a single representation of a single element, but didn't provide a way to span multiple elements as would be the case on a building floor plan. It was possible to link dimensions to objects very simplistically using IfcAnnotation->IfcRelAssignsToProduct->IfcElement (subtype), as documented at IfcAnnotation now, though that really wouldn't address the more typical case of a dimension line, e.g. starting at the outside edge of an exterior wall and spanning to the center line of an interior wall.

I don't have much hindsight, as dimensioning was introduced before my involvement with IFC.

That said, it would seem theoretically possible to make associative dimensioning work with the entities in IFC4 if there is such demand. One could use IfcAnnotation with reserved ObjectType identifiers and additional property sets, where a top-level IfcAnnotation could indicate a dimension line spanning across the sheet, then aggregated IfcAnnotations could indicate each point along the line (between dimension intervals), where each would be linked to an element using IfcRelAssignsToProduct. Lots of abstractions though and not strongly typed.

from ifc4-cv.

I would think that if we were to reintroduce dimensioning at some point, we should introduce constraints, not annotations. Constraints, in my mind, are the true BIM concepts here, useful not only for floor plans but for product libraries as well. The important part of the dimension is not how it looks, but how it associates multiple sub-element references. Getting how it looks correct seems to me a nice bonus, not the main feature.

from ifc4-cv.

My vote would be to develop some type of associative dimension as @timchipman suggests.

As suggested above, those associations would be within the model (spanning elements), but I think they should work with 2D annotation/linework, as well.

In general, as a practitioner, i still think developing standards around the 'presentation of data', is still important, and will continue to be important in the future.

On another note, with the growing number of developments using the BCF and markup on 2-dimensional snapshots, these depreciated entities might make more sense now.

General question, is there that much overhead in keeping these entities in the IFC4 Schema?... because in the end, it's all about MVD implementation. Will get to a point, and i hope it does and as @AngelVelezSosa hints at in this comment, that vendors/user will start creating their own MVD customizations--why truncate the alphabet?

from ifc4-cv.

No. Ryan, I must protest at this moment. I feel like you're hijacking the Coordination View to do more than its intended purpose. If you want "drawings" and annotation exchanges, then I think this is an ENTIRELY different MVD with a entirely different IDM (business case, workflows, exchange requirements).

from ifc4-cv.

My argument here was not about incorporating these depreciated 2D entities into CV2.0, but that they are depreciated, all together, from the IFC4 schema.

I would agree they would be perhaps better associated with a view like FM Handover, or the like.

from ifc4-cv.

The general scope of IFC is to support (using the good old Autocad terms) the "model space", the "paper space" is identified as being out of scope of IFC (this had been identified lately during the IFC2x3 time frame. Dimensions are usually regarded as "paper space" entities, as long as they are annotations of a plan projection (with scale, etc.).

The reason to deprecate those dimension related entities (introduced before IFC2x3) has been to clarify that such "paper space" information is not in scope. If dimension is used as just an "model space" annotation, it could still be included as lines & text (but not in coordination view), but we see no need to identify a callout (marker, leader, etc.).

What would really be interesting, and I agree to @AngelVelezSosa, is to think of dimensions as constraints in a BIM context (bi-directional, associative dimensions), so this could be a future development directions, but not the old "paper space" dimensions.

from ifc4-cv.

By that logic, should entities like IfcAnnotationFillArea, IfcTextLiteralWithExtent, for example, be deprecated, as well?

These are currently in FM handover view.. from what i can gather.

from ifc4-cv.

@theoryshaw - the most recent FM Handover View is here:
http://docs.buildingsmartalliance.org/MVD_COBIE/

This doesn't include those entities (or any geometry for that matter). Not sure where you are seeing these?

I agree that associative constraints would be very useful to add, perhaps in "Parametric View" if/when that happens (IfcRelAssociatesConstraint, etc.).

from ifc4-cv.

Hi Tim,

Thank you for the link.

These entities were exported via Revit's IFCexporter (FM Handover setting) and did not export under (CV 2.0), so assumed they were associated with FM...apparently it's a Revit implementation scenario.

Still hesitant on these 2d entities being retired, all together, from IFC4 schema, but will close issue nonetheless.

If i'm understanding correctly, I do like the 3-dimensional dimensions (constraints) as well. Perhaps another Github issue could be started, in this regard?

Cheers

from ifc4-cv.