# Can WorldCoordinateSystem be removed?

**URL:** <https://forums.buildingsmart.org/t/can-worldcoordinatesystem-be-removed/3492>\
**Category:** Developers\
**Created:** [March 30, 2021, 7:17am UTC](https://forums.buildingsmart.org/t/can-worldcoordinatesystem-be-removed/3492 "2021-03-30T07:17:50Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\
**Post date:** [March 30, 2021, 7:17am UTC](https://forums.buildingsmart.org/t/can-worldcoordinatesystem-be-removed/3492/1 "2021-03-30T07:17:50Z")

</div>

`IfcGeometricRepresentationContext` has `WorldCoordinateSystem`. This `WorldCoordinateSystem` attribute looks suspiciously to me like a predecessor to the IFC4 geolocation entities. Evidence:

> 8.18.3.3 IfcGeometricRepresentationContext  
> In addition it can be used to offset the project coordinate system from a global point of origin, using the _WorldCoordinateSystem_ attribute

The problem is when `WorldCoordinateSystem` has a value, see quote:

> The _TrueNorth_ attribute should be provided, if the y axis of the _WorldCoordinateSystem_ does not point to the global northing. Direction of the true north, or geographic northing direction, relative to the underlying project coordinate system as established by the attribute _WorldCoordinateSystem_ .

In [my other thread describing the complexities of grid, true, and magnetic north in IFC](https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491) this creates a further complication. This sounds like the first attempt to specify grid north, but it also kinda describes itself as a replacement for true north, which is not correct.

Finally, there is this very strange quote which suggests that even if the new geolocation entities are used, it still has a purpose of some kind (emphasis mine):

> If an geographic placement is provided using [IfcMapConversion](http://localhost:8001/schema/ifcrepresentationresource/lexical/ifcmapconversion.htm) then the _WorldCoordinateSystem_ atttibute **is used to define the offset between the zero point of the local engineering coordinate system and the geographic reference point to which the [IfcMapConversion](http://localhost:8001/schema/ifcrepresentationresource/lexical/ifcmapconversion.htm) offset relates**. In preferred practise both points (also called “project base point” and “survey point”) should be coincidental. However it is possible to offset the geographic reference point from the local zero point.

I’ve read it a few times and I still don’t get it.

There is an interesting aspect of product placement, suggesting that it is used for absolute placement.

> 4.8.1.1 Product Local Placement  
> In certain use cases, an absolute placement may be used by omiting(sic) the [IfcObjectPlacement](http://localhost:8001/schema/ifcgeometricconstraintresource/lexical/ifcobjectplacement.htm). In this case, the shape representation is defined within the world coordinate system.

This is some real trippy stuff. Since local placements basically jump up the local placement tree until you hit the end, and then to go to global (i.e. real world coordinates) you apply IfcMapConversion. Grid placements are relative to a grid, and then to go global, again, you apply IfcMapConversion. But … absolute placements are … well, not actually absolute, they are relative to the WorldCoordinateSystem, which is kinda already an “offset from a global point of origin” (quoted from the docs) … and then apply IfcMapConversion on top? It … just … what?

My conclusion: WorldCoordinateSystem is superseded by IfcMapConversion.

Proposal: delete WorldCoordinateSystem. Make absolute positions actually absolute.

I hope someone can help clarify this for me. Or if my conclusion seems correct, hopefully this can be deleted sooner rather than later because geolocation and “where is north” is a really important aspect of BIM.

---

<div class="post-metadata">

**Author:** ![skogsholm](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/skogsholm/32/648_2.png) [@skogsholm](https://forums.buildingsmart.org/u/skogsholm)\
**Post date:** [April 14, 2021, 9:25am UTC](https://forums.buildingsmart.org/t/can-worldcoordinatesystem-be-removed/3492/2 "2021-04-14T09:25:26Z")

</div>

As you have seen before, my interpretation, given that IfcMapConversion is used, is that WorldCoordinateSystem defines the difference/offset between “Survey point” (point for Eastings and Northings) on the map, and “Project Base Point” (absolute zero in the IFC model).

Have you come to another conclusion?  
I agree on this being trippy stuff, and can not see a case where WCS would be needed (help?).

 ![image](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/2X/2/2021a7789c383c9f870acc26ebd5688272607d6d.jpeg)

---

<div class="post-metadata">

**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\
**Post date:** [April 14, 2021, 10:48am UTC](https://forums.buildingsmart.org/t/can-worldcoordinatesystem-be-removed/3492/3 "2021-04-14T10:48:13Z")

</div>

Yeah - I recall that diagram. The conclusion I’m now coming to is that I no longer see any point for WorldCoordinateSystem to exist. I don’t see implementers using it, nor do I see any software reason for it to exist, nor do I see any surveying reason for it to exist.

So I’m proposing to get rid of it and remove the additional complexity.
