IFC4.3.x-development
IFC4.3.x-development copied to clipboard
buildingSMART
HasCoordinateOperation constraint to all contexts cannot be satisfied
Original issue: https://forums.buildingsmart.org/t/hascoordinateoperation-constraint-to-all-contexts-cannot-be-satisfied/3502
The docs state:
Indicates conversion between coordinate systems. In particular it refers to an IfcCoordinateOperation between a Geographic map coordinate reference system, and the engineering coordinate system of this construction project. If there is more then one IfcGeometricRepresentationContext provided to the IfcProject then all contexts shall have an identical instance of IfcCoordinateOperation as HasCoordinateOperation refering to the same instance of IfcCoordinateReferenceSystem.
HasCoordinateOperation is an inverse attribute, which points to an IfcCoordinateOperation (i.e. an IfcMapConversion. Specifically, the SourceCRS refers to the IfcGeometricRepresentationContext, and the TargetCRS refers to the IfcProjectedCRS.
Therefore, it is impossible to have an identical instance of IfcCoordinateOperation. You will need a newIfcMapConversion per context. This is, well, not very good. All contexts should have the same map conversion, unless you want users brains to explode :slight_smile:
An additional impact of this is that it becomes mandatory to have an IfcMapConversion, otherwise your IfcProjectedCRS is not going to be linked to your context. (Note: technically speaking you could have an IfcProjectedCRS without an IfcMapConversion but the entity is unrelated, which is also pretty poor). Some might argue that this is not quite correct, as in theory you might want a situation where you have an IfcProjectedCRS without any conversion (i.e. your geometric context is already in the map CRS). This happens a lot of civil / infrastructure projects, I would imagine.
Funnily enough, it is also exactly in this scenario which makes the true north attribute a bit meaningless, since it is no longer clear which easting / northing is being specified. Related to #315.
You will need a new IfcMapConversion per context. This is, well, not very good.
Yes, you need a new IfcMapConversion per context, and I find this very good! Imagine two bridges along an alignment, each with its own, local engineering CRS. Each gets its own geometric context with its own IfcMapConversion to translate and rotate the local coordinates to a global CRS. Thus, you'd have three contexts: bridge A, bridge B, and alignment.
Following this, the documentation needs updating: the sentence "If there is more ... " shall be deleted. I'm open for discussion, if there should be a restriction, that all IfcCoordinateOperation within the same IfcProject shall refer to the same instance of IfcCoordinateReferenceSystem.
it becomes mandatory to have an IfcMapConversion
I'm all for this. In the end, we're not building anything in the clouds.
where you have an IfcProjectedCRS without any conversion
Use zeros in IfcMapConversion.
which makes the true north attribute a bit meaningless
I'd say completely meaningless.
Cool! Your explanation makes sense. I'm not a domain expert in infra / gis so would you mind translating your comments into a proposal? Also ping @SergejMuhic and @LeeGregory12d is what @pjanck saying making sense?
true north is an attribute introduced in early versions of IFC way before IfcCoordinateReferenceSystem +++ had been added in IFC4 time frame. It can be either deprecated, or add a note, that it should only be used, if the file is not georeferenced via IfcCoordinateReferenceSystem
Sure, there are currently many ways of expressing this. One thing we lose though is that semantically TrueNorth has quite the explicit meaning and is therefore really nice from the point of view of documenting the concept.
@SergejMuhic @pjanck agreed - I've referenced #323 which solves the true north issue. If we come to an agreement on #323 we can also solve this issue.
(note deprecation of entity attribute is currently a md only change and can be done by anybody)
the documentation needs updating: the sentence "If there is more ... " shall be deleted.
Has somebody done this?
This issue is not about the deprecation of true north - that is a separate issue that is being resolved in #323 .
This issue is about the cardinality of the SourceCRS in IfcCoordinateOperation. We have this situation:
IfcGeometricRepresentationContext --HasCoordinateOperation S[0:1]-->IfcCoordinateOperation
and inversely:
IfcGeometricRepresentationContext <--SourceCRS [1:1]-- IfcCoordinateOperation
This means that each each representation context has its own coordinate operation.
This raises 3 questions:
- Is it good or bad for each context to have its own coordinate operation? @pjanck says this is a good thing. Great! Maybe no issue here. Can we get a second opinion to confirm?
- Is it good or bad for each context to mandate a new coordinate operation instance? This means that if you have a Model view and then a Plan view that correlates, you have to enter in all the map conversion attributes twice and you get duplication of data. So now users need to be extra careful that if they change one, they have to change the others too? There is no software link between two "duplicated" map conversions.
- If what @pjanck says is correct, i.e "Each gets its own geometric context with its own IfcMapConversion to translate and rotate the local coordinates to a global CRS. Thus, you'd have three contexts: bridge A, bridge B, and alignment." - this is a huge impact on developers. How are models merged? How are models federated in a viewer? When a new entity is created in an IFC model, is the user meant to have a list of available contexts for it to be assigned to? I'm not saying it's a bad thing, but what I am saying is that it is a huge change to how contexts were previously used (as simply a categorisation of geometries dimensionality, classification (body, annotation) and target view (top down, sectional) and target scale, not coordinate system) ... and there is no documentation that I can spot (have I missed it?) which describes this fundamental change.
The third issue is a main concern. It is paradigm shift in how geometric contexts are used.
I would propose a change in cardinality so that SourceCRS becomes S[0:N] - that way many contexts can share the same coordinate operation if they indeed are in the same coordinate space ... but that is not the whole solution. Because how do you have three contexts for 2 bridges and an alignment? Do you have three Model contexts? How does software interpret that? How do you say "this model context" is for bridge? Where do you give it a name?
Quite a summary! :) A lot to unpack, I'll try my best - I may have missed something.
you get duplication of data
This is of course sub-optimal. However, changing the cardinality of SourceCRS from 1 to many is a breaking change for serialization that I'm reluctant to approve (although I also don't have a counter proposal that would be better at this time). Perhaps this is something for IFC5?
There is no software link between two "duplicated" map conversions.
Which software are you referring to? I don't understand the problem.
How are models merged? How are models federated in a viewer?
Well, you've just summarized my PhD topic in two short questions. :) The answer is not trivial. And definitely not short enough for a GitHub issue answer.
See https://github.com/bSI-InfraRoom/IFC-infra-unit-test/pull/85 for an example named Georeferencing-4 at how I think this can be done.
When a new entity is created in an IFC model, is the user meant to have a list of available contexts for it to be assigned to?
Good approach, yes.
I'm not saying it's a bad thing, but what I am saying is that it is a huge change to how contexts were previously used (as simply a categorisation of geometries dimensionality, classification (body, annotation) and target view (top down, sectional) and target scale, not coordinate system)
Well, each geometric representation context defines a coordinate system in its 5th attribute WorldCoordinateSystem, so I'd say the usage does not change even a bit. That's the point of having the context IMO.
The third issue is a main concern. It is paradigm shift in how geometric contexts are used.
Yes to main concern. Again, my PhD topic :) Still writing, though ...
I wouldn't say that it is a huge paradigm shift now - it was when the whole thing was introduced in IFC4.
Do you have three Model contexts?
Yes.
How does software interpret that?
Good question. As three contexts? See Georeferencing-4 example mentioned above.
How do you say "this model context" is for bridge?
Do you mean during the creation of a model in software, or during the creation of an IFC dataset? For the former: anyway you see fit; for the latter: link geometries to the correct context. Or am I misunderstanding the question?
Where do you give it a name?
Name of the context? IfcRepresentationContext::ContextIdentifier would be my guess.
There is no software link between two "duplicated" map conversions.
Any software has no way of knowing that two MapConversions are meant (i.e. intended by the authoring user) to be identical.
Well, each geometric representation context defines a coordinate system in its 5th attribute WorldCoordinateSystem, so I'd say the usage does not change even a bit. That's the point of having the context IMO.
Great justification, I retract my argument there and you are correct :)
Name of the context? IfcRepresentationContext::ContextIdentifier would be my guess.
I guess too - there's nowhere else to put it :( This is all assumptions and not documented.
Well, you've just summarized my PhD topic in two short questions. :) The answer is not trivial. And definitely not short enough for a GitHub issue answer.
OK - let's hold off on this, and I'd love to test your sample file when I get some time in the coming months or so. I have the luxury of being a non-domain expert, so if we can distill the complexities of what takes a PhD to solve into a simple but extensible thing that non-experts like myself can understand, that'd be a huge win.
Perhaps this is something for IFC5?
Yes, agreed. Can I confirm that for now in IFC4.3 we just need to have multiple contexts, each with its own map conversion? If so, perhaps we can at least improve the documentation and write a sentence or two about it. Can you propose some sentences to write?