I was unable to export ifc from imported cityjson. I did manage to work it out using citygml. That works quite well for 3DBAG. For the groundsurface i doubt if this will be efficient to do it the ifc wsy. Does everthing needs to be ifc..?
Geometry has value. Nevermind the format. I personally. m much more interested in getting geometry over from gis to 3d cad then 'bimdata', if the carrier is ifc, well fine..
What suggestions to store these Dutch 'LoD2.2' models? In what format to work with ? I mean, to connect to the worlds, the one of BuildingSmart to OCG? I see cityjson and ifc.
What suggestions to store these Dutch 'LoD2.2' models? In what format to work with ?
For pure geometry and faces I can think of stl, obj, dae, step, iges, brep
IFC compliant software will always look for the BIM data attached to geometry so I guess there is no point and utility in storing only geometry in IFC
This data is provided as .obj but it very difficult to get this into normal CAD/BIM software. I'm talking Autodesk Revit or Autodesk (alternatives). Forgive me the Autodesk background..
But besides cityjson the .obj format needs an extra conversions because of lack of compatibility between gis and cad/bim.
Maybe we have agree to disagree :) but i would say 3d buildings coming from GIS national assetmanagent could be, should be ifc compatible for use. Skip the converting..
It is actually also not true that there is no metadata. The metadata is just decoupled from the geometry, because there are different LoDs. For example, there is information about roof type (see picture). In LoD2.2, all the metadata is found on the hierarchical level of the building and not individual elements (apparently). Eventually, if LoD is increased, material information etc. would be found on the roof/wall/floor surfaces too. So it will definitely make sense to have some form of compatibility between cityJSON/cityGML and IFC. Highest LoD in the GIS standard even captures indoor information.
@LaurensJN great! If we came up with a mapping, we could do a converter! A stop-gap solution would be to dump it in a Pset. @magicalcloud_75 you can simply create a new IFC project, move all the objects into the relevant location in the spatial tree (e.g. IfcSite), then assign a class IfcBuilding. You will need to change the aggregation to be IfcSite.
@Moult that would be neat! The CityGML/JSON format is also quite bulky and probably has a lot of overlapping elements / attributes, but probably also a lot that are not found in IFC so it'd be quite a task I think. But adding all metadata as (in this case BAG-)pset would be the way to go at first yes.
Is there any way to change the aggregation using a script or by selecting all objects and do it at once? I was trying to make an IFC and got stuck with elements that were not in the correct spatial hierarchy. Changing aggregation of 800 buildings one-by-one does not seem to be the fastest solution :)
@LaurensJN it may be worthwhile writing a City2IFC conversion script, so we don't require the overhead of Blender. That way, it can probably also handle geolocation conversion. Unfortunately, this requires me reading the City{GML,JSON} spec, which I don't quite have the time for. But it would be a great exercise for someone else on this forums who wants to practice their Python?
In the meantime, this commit allows you to change aggregations of all selected objects:
@Moult I could try to hack something together, although I'm unsure if I have all the skills for that. I don't think the geolocation will be the problem, rather the geometry itself as it has its own way of defining the geometries. There is a cityjson python parser (cjio or CityJSON /IO) that might be useful for conversion.
Actually, that wasn't so difficult at all! I used the IfcOpenShell library and the cjio library to convert the json file to an IFC file and here is the result imported in Blender. Geometry wasn't the worst, because cityjson only uses brep representations.
It's not perfect, mostly because I'm not such an expert in IfcOpenShell (for example I did not yet get the aggregations quite right), but it's surely a start. I could try to set up a github repository somewhere so others could try?
@LaurensJN fantastic work! Set up a repo somewhere - and why not we make it part of the IfcOpenShell umbrella! We can all collaborate to help polish it.
I made a repo here: https://github.com/LaurensJN/CJ2IFC. Code's a mess still, but the example works so that's something :)
I'm totally up for including this in the IfcOpenShell repo, but I have no clue how so I'd need your help there.
The whole idea of CityJSON is a compact schema that reduces the metadata overhead found in for example CityGML that is much more verbose. IFC is, like CityGML, a very verbose schema & therefore it is expected that file size explodes if you convert big CityJSON files. There is no other way, except for further tiling the CityJSON file into smaller parts (not super easy but possible with the CJIO python module), or removing elements that you don't need.
There is always a trade-off between reduced file size (only geometry, preferably topology to even reduce file size more) and full metadata. It's your call what is most important to you. If you are looking for the geometry only, CJIO provides different exports for CityJSON: ['obj', 'jsonl', 'stl', 'glb', 'b3dm']. I guess exports to obj file would reduce the file size and is widely supported (you can for example import it in blender). See here how to use it: https://cjio.readthedocs.io/
If we disregard file sizes, the converter works for any CityJSON file, so yes. It might be not too useful, because these kind of files contain mostly infrastructure / land use etc. There is no support in IFC4 (yet) for these kind of classes. However, if IFC4.3 becomes a real standard, there could be some advantages to convert CityJSON basisvoorziening to IFC.
"__contain mostly infrastructure / land use __"
That's exactly what i would like to use it for. Consider a medium to large infrastructure project. The correct building shape is not so relavant. Getting the true height to the mm. of ground level is also not that important. Dataset 3D Basisvoorziening however could be useful to get a fast view that the site is about.
If IFC4.3 has the ability to get IFC work together with Cityjson, we should use it. By 'we' i mean , people and stakeholders in general!
Dooooo..
It just reminded me Up3date is already able to import cityjson. https://github.com/cityjson/Up3date
Still, there is much to gain. The import proces is about 2 hours for 1.5 GB! Which i find not acceptabel values
Maybe Blender 3.0 does it faster but i doubt it.
Comments
3D BAG to DXF to IFC gives better building geometry. Blenderbim does not seem to export cityjson to .ifc Why? Settings?
Not sure what you mean - if it's geometry, it can be captured in IFC, even without metadata.
I was unable to export ifc from imported cityjson. I did manage to work it out using citygml. That works quite well for 3DBAG. For the groundsurface i doubt if this will be efficient to do it the ifc wsy. Does everthing needs to be ifc..?
There is no benefit to storing raw geometry in IFC if that is the only thing that is stored. The value of IFC comes in its BIM metadata.
Geometry has value. Nevermind the format. I personally. m much more interested in getting geometry over from gis to 3d cad then 'bimdata', if the carrier is ifc, well fine..
What suggestions to store these Dutch 'LoD2.2' models? In what format to work with ? I mean, to connect to the worlds, the one of BuildingSmart to OCG? I see cityjson and ifc.
For pure geometry and faces I can think of
stl,obj,dae,step,iges,brepIFC compliant software will always look for the BIM data attached to geometry so I guess there is no point and utility in storing only geometry in IFC
This data is provided as .obj but it very difficult to get this into normal CAD/BIM software. I'm talking Autodesk Revit or Autodesk (alternatives). Forgive me the Autodesk background..
But besides cityjson the .obj format needs an extra conversions because of lack of compatibility between gis and cad/bim.
Maybe we have agree to disagree :) but i would say 3d buildings coming from GIS national assetmanagent could be, should be ifc compatible for use. Skip the converting..
For CAD alternatives I would look into
igeswhich you can use FreeCAD I believe to do soIt is actually also not true that there is no metadata. The metadata is just decoupled from the geometry, because there are different LoDs. For example, there is information about roof type (see picture). In LoD2.2, all the metadata is found on the hierarchical level of the building and not individual elements (apparently). Eventually, if LoD is increased, material information etc. would be found on the roof/wall/floor surfaces too. So it will definitely make sense to have some form of compatibility between cityJSON/cityGML and IFC. Highest LoD in the GIS standard even captures indoor information.
I use the german FZK viewer to make it IFC but i think Blender would be a way better tool. How can it be done?
@LaurensJN great! If we came up with a mapping, we could do a converter! A stop-gap solution would be to dump it in a Pset. @magicalcloud_75 you can simply create a new IFC project, move all the objects into the relevant location in the spatial tree (e.g. IfcSite), then assign a class IfcBuilding. You will need to change the aggregation to be IfcSite.
@Moult that would be neat! The CityGML/JSON format is also quite bulky and probably has a lot of overlapping elements / attributes, but probably also a lot that are not found in IFC so it'd be quite a task I think. But adding all metadata as (in this case BAG-)pset would be the way to go at first yes.
Is there any way to change the aggregation using a script or by selecting all objects and do it at once? I was trying to make an IFC and got stuck with elements that were not in the correct spatial hierarchy. Changing aggregation of 800 buildings one-by-one does not seem to be the fastest solution :)
Let me link and share this ..
https://geoforum.nl/t/export-3d-bag-from-qgis/5679/7
@LaurensJN it may be worthwhile writing a City2IFC conversion script, so we don't require the overhead of Blender. That way, it can probably also handle geolocation conversion. Unfortunately, this requires me reading the City{GML,JSON} spec, which I don't quite have the time for. But it would be a great exercise for someone else on this forums who wants to practice their Python?
In the meantime, this commit allows you to change aggregations of all selected objects:
https://github.com/IfcOpenShell/IfcOpenShell/commit/cab9e4d892a971774ae1fade031f9298b98e0bb7
@Moult I could try to hack something together, although I'm unsure if I have all the skills for that. I don't think the geolocation will be the problem, rather the geometry itself as it has its own way of defining the geometries. There is a cityjson python parser (cjio or CityJSON /IO) that might be useful for conversion.
Actually, that wasn't so difficult at all! I used the IfcOpenShell library and the cjio library to convert the json file to an IFC file and here is the result imported in Blender. Geometry wasn't the worst, because cityjson only uses brep representations.
It's not perfect, mostly because I'm not such an expert in IfcOpenShell (for example I did not yet get the aggregations quite right), but it's surely a start. I could try to set up a github repository somewhere so others could try?
@LaurensJN fantastic work! Set up a repo somewhere - and why not we make it part of the IfcOpenShell umbrella! We can all collaborate to help polish it.
I made a repo here: https://github.com/LaurensJN/CJ2IFC. Code's a mess still, but the example works so that's something :)
I'm totally up for including this in the IfcOpenShell repo, but I have no clue how so I'd need your help there.
@LaurensJN could your plugin work to import and use Cityjson files from '3D basisvoorsiening'. If so, this would be really a great feature for Blender.
https://3d.kadaster.nl/basisvoorziening-3d/
The Cityjson (1 subtile of the 4) converted to .ml gives a file of about 3.7 GB. That's too big to handle.
Buildings are not good. Needs LOD2.2 from BAG.
In FZKviewer this tools like this
Target Area
There seems to be not an option to isolate a selection and delete the rest
Atempt to export the ENTIRE tile.
Cancelled the proces at 9%. The ifc blow up to 5 GB and counting..! This is not the way
The whole idea of CityJSON is a compact schema that reduces the metadata overhead found in for example CityGML that is much more verbose. IFC is, like CityGML, a very verbose schema & therefore it is expected that file size explodes if you convert big CityJSON files. There is no other way, except for further tiling the CityJSON file into smaller parts (not super easy but possible with the CJIO python module), or removing elements that you don't need.
There is always a trade-off between reduced file size (only geometry, preferably topology to even reduce file size more) and full metadata. It's your call what is most important to you. If you are looking for the geometry only, CJIO provides different exports for CityJSON: ['obj', 'jsonl', 'stl', 'glb', 'b3dm']. I guess exports to obj file would reduce the file size and is widely supported (you can for example import it in blender). See here how to use it: https://cjio.readthedocs.io/
If we disregard file sizes, the converter works for any CityJSON file, so yes. It might be not too useful, because these kind of files contain mostly infrastructure / land use etc. There is no support in IFC4 (yet) for these kind of classes. However, if IFC4.3 becomes a real standard, there could be some advantages to convert CityJSON basisvoorziening to IFC.
"__contain mostly infrastructure / land use __"
That's exactly what i would like to use it for. Consider a medium to large infrastructure project. The correct building shape is not so relavant. Getting the true height to the mm. of ground level is also not that important. Dataset 3D Basisvoorziening however could be useful to get a fast view that the site is about.
If IFC4.3 has the ability to get IFC work together with Cityjson, we should use it. By 'we' i mean , people and stakeholders in general!
Dooooo..
It just reminded me Up3date is already able to import cityjson.
https://github.com/cityjson/Up3date
Still, there is much to gain. The import proces is about 2 hours for 1.5 GB! Which i find not acceptabel values
Maybe Blender 3.0 does it faster but i doubt it.