@Moult Ok I got it, I was close in the beginning but it didn't help much the fact that I was writing without any debugging, then copy pasting the code in the blenderbim folder to try it and only read the error. I guess for any further work i will have to understand how to operate better.
In any case, I have done an implementation that looks like it works. Should I just push directly to v0.6.0?
I don't know how can I help, but if at the end it causes we have a glTF/WebGL web viewer I'd be happy to help
IFC --> Geometry + Semantics --> JSON + glTF/3D Tiles
It seems that JSON and JSON-LD has a lot of similarities, but in some areas are different, so in semantics side for sure APIs like OpenAPI and also JSON, and JSON-LD will play vital roles among other SQL-based movements
If anyone wants we have an advanced web viewer that can handle huge data, not small or medium-sized data and is interested in 3D Tiles, let's build a giant solution
the IFC schema is identical for both JSON and SPF - they are simply two formats of representing data from the same schema, so there is no conversion.
Let's say we have this test file, so how do we map it to YAML or JSON? or SQL/SQLite (yes I know that there's IFC# however I just want Types and Entity Types without parent/child)?
TYPE IfcBoolean = BOOLEAN;
END_TYPE;
TYPE IfcLogical = LOGICAL;
END_TYPE;
TYPE IfcBinary = BINARY;
END_TYPE;
TYPE IfcPHMeasure = REAL;
WHERE
WR21 : {0.0 <= SELF <= 14.0};
END_TYPE;
TYPE IfcCountMeasure = NUMBER;
END_TYPE;
TYPE IfcDayInMonthNumber = INTEGER;
WHERE
ValidRange : {1 <= SELF <= 31};
END_TYPE;
TYPE IfcFontWeight = STRING;
WHERE
WR1 : SELF IN ['normal','small-caps','100','200','300','400','500','600','700','800','900'];
END_TYPE;
TYPE IfcBoxAlignment = IfcLabel;
WHERE
WR1 : SELF IN ['top-left', 'top-middle', 'top-right', 'middle-left', 'center', 'middle-right', 'bottom-left', 'bottom-middle', 'bottom-right'];
END_TYPE;
TYPE IfcComplexNumber = ARRAY [1:2] OF REAL;
END_TYPE;
TYPE IfcPropertySetDefinitionSet = SET [1:?] OF IfcPropertySetDefinition;
END_TYPE;
TYPE IfcCompoundPlaneAngleMeasure = LIST [3:4] OF INTEGER;
WHERE
MinutesInRange : ABS(SELF[2]) < 60;
SecondsInRange : ABS(SELF[3]) < 60;
MicrosecondsInRange : (SIZEOF(SELF) = 3) OR (ABS(SELF[4]) < 1000000);
ConsistentSign : ((SELF[1] >= 0) AND (SELF[2] >= 0) AND (SELF[3] >= 0) AND ((SIZEOF(SELF) = 3) OR (SELF[4] >= 0)))
OR
((SELF[1] <= 0) AND (SELF[2] <= 0) AND (SELF[3] <= 0) AND ((SIZEOF(SELF) = 3) OR (SELF[4] <= 0)));
END_TYPE;
TYPE IfcActionRequestTypeEnum = ENUMERATION OF
(EMAIL
,FAX
,PHONE
,POST
,VERBAL
,USERDEFINED
,NOTDEFINED);
END_TYPE;
TYPE IfcActorSelect = SELECT
(IfcOrganization
,IfcPerson
,IfcPersonAndOrganization);
END_TYPE;
ENTITY IfcDerivedUnit;
Elements : SET [1:?] OF IfcDerivedUnitElement;
UnitType : IfcDerivedUnitEnum;
UserDefinedType : OPTIONAL IfcLabel;
DERIVE
Dimensions : IfcDimensionalExponents := IfcDeriveDimensionalExponents(Elements);
WHERE
WR1 : (SIZEOF (Elements) > 1) OR ((SIZEOF (Elements) = 1) AND (Elements[1].Exponent <> 1 ));
WR2 : (UnitType <> IfcDerivedUnitEnum.USERDEFINED) OR
((UnitType = IfcDerivedUnitEnum.USERDEFINED) AND
(EXISTS(SELF.UserDefinedType)));
END_ENTITY;
ENTITY IfcCoordinateReferenceSystem
ABSTRACT SUPERTYPE OF (ONEOF
(IfcProjectedCRS));
Name : IfcLabel;
Description : OPTIONAL IfcText;
GeodeticDatum : OPTIONAL IfcIdentifier;
VerticalDatum : OPTIONAL IfcIdentifier;
INVERSE
HasCoordinateOperation : SET [0:1] OF IfcCoordinateOperation FOR SourceCRS;
END_ENTITY;
I think you may be mixing a few concepts here. The way IFC works is that there is a "schema" defined using "EXPRESS". Data which conforms to the schema may then be represented using multiple possible formats, including IFC-SPF (.ifc), IFCJSON (.ifcjson), IFCZIP (.ifczip), IFCXML (.ifcxml), etc. You can convert the "data" to/from each format. So when we say "convert IFC to JSON" we usually mean converting IFC "data" in the "IFC-SPF" format (.ifc) into the "IFCJSON" format (.ifcjson).
What you're describing is converting the EXPRESS schema into a JSON syntax. Nothing has been defined for this to my knowledge. You could certainly invent an arbitrary mapping, but nothing would be currently able to parse it meaningfully.
For example, arbitrarily you could convert this EXPRESS statement:
It doesn't add any much value, apart from perhaps from writing a new IFC library from scratch and if you for some reason didn't want to parse EXPRESS and instead wanted to parse JSON. In fact, it is likely to be less useful than EXPRESS, since EXPRESS is a data modeling language, and JSON is not.
@Moult did you investigate Google's ontology?
Based on my view it's too basic
So, I want to build a new ontology which is so advanced, this is why I want to map EXPRESS to YAML or JSON or SQLite/SQL So, I want to extract all types from EXPRESS automatically (on average each entity has around six entity types, it means over 6000 types)
Yes, there're IFCOWL and probably we can parse them to JSON-LD, however, maybe I'm wrong, but I haven't seen any project based on JSON-LD yet
Will investigate to see if there's any mapper between EXPRESS and UML or SysML? (to be able to execute code in different formats?)
{
"ActionRequest": [
{
"#": "7",
"Attribute": "PredefinedType",
"Type": "ActionRequestTypeEnum",
"Cardinality": "?",
"Description": "Identifies the predefined type of sources through which a request can be made."
},
{
"#": "8",
"Attribute": "Status",
"Type": "Label",
"Cardinality": "?",
"Description": "The status currently assigned to the request. Possible values include:\nHold: wait to see if further requests are received before deciding on action\nNoAction: no action is required on this request\nSchedule: plan action to take place as part of maintenance or other task planning/scheduling\nUrgent: take action immediately"
},
{
"#": "9",
"Attribute": "LongDescription",
"Type": "Text",
"Cardinality": "?",
"Description": "Detailed description of the permit."
}
],
"Actor": [
{
"#": "6",
"Attribute": "TheActor",
"Type": "ActorSelect",
"Description": "Information about the actor."
},
{
"Attribute": "IsActingUpon",
"Type": "RelAssignsToActor@RelatingActor",
"Cardinality": "S[0:?]",
"Description": "Reference to the relationship that associates the actor to an object."
}
],
"Rail": [
{
"#": "9",
"Attribute": "PredefinedType",
"Type": "RailTypeEnum",
"Cardinality": "?"
}
]
}
This ifcjson sounds interesting.
If we would be able to somehow splitt it into Geometry and all other information and do put these ifcjson without geometry on a git, we might be able to use diff and gitlab and gitlab diffviewing to get something meandingfull for different versions of a ifc modell.
How does this sounds?
I allready did experiments to put all informations from ifc into yaml save the geometry of each object into a brep (a small ifc to keep parametrices would be possible too) and put it on a github. Works quite good and diff between modell versions is very fast and full usabable in real world projects (except geometry, but this was not the idea .)
It even works to construct back a ifc from the yaml and brep data.
This is why I think decoupling geometry and semantics (and generally decoupling everything) is a great idea
I'm not a fan of JSON/YAML or XML, I like SQL/SQLite, however, last night tested a trick to see if is it possible to import IFC schema/spec HTML tables into Excel and then convert those tables into JSON? And that worked
However, still, this is manual and needs some automation (for instance use a web crawler)
Or the best approach: Parse EXPRESS into JSON/YAML and/or SQL/SQLite (Which EXPRESS into JSON soon will be possible)
Comments
@Jesusbill
ifc_file = self.file@Moult Ok I got it, I was close in the beginning but it didn't help much the fact that I was writing without any debugging, then copy pasting the code in the blenderbim folder to try it and only read the error. I guess for any further work i will have to understand how to operate better.
In any case, I have done an implementation that looks like it works. Should I just push directly to v0.6.0?
@Jesusbill sure :) Push, and if there are mistakes, we can fix it as we go!
done
Fantastic work @Jesusbill !
I've published a very simple test model here: https://github.com/Moult/ifc-test-files/blob/master/src/ifcjson/test.ifcjson
Great, thanks @Moult it was fun.
I don't know how can I help, but if at the end it causes we have a glTF/WebGL web viewer I'd be happy to help
IFC --> Geometry + Semantics --> JSON + glTF/3D Tiles
It seems that JSON and JSON-LD has a lot of similarities, but in some areas are different, so in semantics side for sure APIs like OpenAPI and also JSON, and JSON-LD will play vital roles among other SQL-based movements
If anyone wants we have an advanced web viewer that can handle huge data, not small or medium-sized data and is interested in 3D Tiles, let's build a giant solution
I'd like a lot to port this to FreeCAD as well!
@yorik absolutely :) Should be fairly easy!
@Moult what do you mean?
Let's say we have this test file, so how do we map it to YAML or JSON? or SQL/SQLite (yes I know that there's IFC# however I just want Types and Entity Types without parent/child)?
I think you may be mixing a few concepts here. The way IFC works is that there is a "schema" defined using "EXPRESS". Data which conforms to the schema may then be represented using multiple possible formats, including IFC-SPF (.ifc), IFCJSON (.ifcjson), IFCZIP (.ifczip), IFCXML (.ifcxml), etc. You can convert the "data" to/from each format. So when we say "convert IFC to JSON" we usually mean converting IFC "data" in the "IFC-SPF" format (.ifc) into the "IFCJSON" format (.ifcjson).
What you're describing is converting the EXPRESS schema into a JSON syntax. Nothing has been defined for this to my knowledge. You could certainly invent an arbitrary mapping, but nothing would be currently able to parse it meaningfully.
For example, arbitrarily you could convert this EXPRESS statement:
... into ...
It doesn't add any much value, apart from perhaps from writing a new IFC library from scratch and if you for some reason didn't want to parse EXPRESS and instead wanted to parse JSON. In fact, it is likely to be less useful than EXPRESS, since EXPRESS is a data modeling language, and JSON is not.
@Moult did you investigate Google's ontology?
Based on my view it's too basic
So, I want to build a new ontology which is so advanced, this is why I want to map EXPRESS to YAML or JSON or SQLite/SQL
So, I want to extract all types from EXPRESS automatically (on average each entity has around six entity types, it means over 6000 types)
Yes, there're IFCOWL and probably we can parse them to JSON-LD, however, maybe I'm wrong, but I haven't seen any project based on JSON-LD yet
Will investigate to see if there's any mapper between EXPRESS and UML or SysML? (to be able to execute code in different formats?)
Some tests :)
Also, I deleted Ifc prefix :))
This ifcjson sounds interesting.
If we would be able to somehow splitt it into Geometry and all other information and do put these ifcjson without geometry on a git, we might be able to use diff and gitlab and gitlab diffviewing to get something meandingfull for different versions of a ifc modell.
How does this sounds?
I allready did experiments to put all informations from ifc into yaml save the geometry of each object into a brep (a small ifc to keep parametrices would be possible too) and put it on a github. Works quite good and diff between modell versions is very fast and full usabable in real world projects (except geometry, but this was not the idea .)
It even works to construct back a ifc from the yaml and brep data.
cheers bernd
This is why I think decoupling geometry and semantics (and generally decoupling everything) is a great idea
I'm not a fan of JSON/YAML or XML, I like SQL/SQLite, however, last night tested a trick to see if is it possible to import IFC schema/spec HTML tables into Excel and then convert those tables into JSON? And that worked
However, still, this is manual and needs some automation (for instance use a web crawler)
Or the best approach: Parse EXPRESS into JSON/YAML and/or SQL/SQLite (Which EXPRESS into JSON soon will be possible)