0

I have developed an application that gets the JSON object tree of a BIM 360 revit model's view, using the Forge Model Derivative endpoint, then downloads the SQLite PropertyDatabase to query properties of several object tree entities. That was working fine until now. Recently, I am having trouble with some models where the object tree derivative object ids don't match the PropertyDatabase object ids.

I have seen this post Temporary workaround for mapping between SVF1 and SVF2 IDs but this method is not valid in my case because my app works on the server side and not uses viewer API at all.

My question is: if there is a workaround using APIs from the server side, and if there are plans to solve this inconsistency between APIs shortly.

migueaguilera
  • 13
  • 5

1 Answers1

1

Unfortunately, this behaviour is expected with your approach. SVF and SVF2 do not share the same IDs, SVF2 IDs are optimised to process data faster and to try keeping them identical across versions. The article you make reference to is only working in the context of the Viewer, for server side processing you need to get the dbid.idx file to map IDs. This utility has a command to help you downloading the file. Try:

./forge.js version-svf2-idmap project_id version_id output_dbid.idx

This file is a gzip compressed file of a uint32 array.

What happened is that you did download the SVF SQLlite db using SVF ids. But when using the MD endpoints, you actually using the SVF2 ids because the target format is SVF2. If you did request a SVF target format, the MD endpoint would work with SVF ids. Unfortunately, you do not control BIM360 target format which could either be SVF or SVF2 depending of the source file format. For example, IFC, RVT, NWD, DWG are SVF2, but others are not. You can determine which format is used by reading the outputType and overrideOutputType. If overrideOutputType says 'svf2', then you should do the mapping.

The relevant code for the version-svf2-idmap is here

On the other hand, if you got the SQLite database, why do you need to call the MD endpoints, you got everything you need, and can extract the information much faster from there. See my example here. It has functions for properties extraction, and/or building the hierarchy tree.

cyrille
  • 2,616
  • 1
  • 10
  • 18
  • Thank you very much @cyrille, that code is a valuable resource, it sure helps me. I know PropertyDb contains the hierarchy of objects, but calling the Model Derivative endpoint seems to me an easier and faster way to obtain exactly the same tree of objects that is shown in the viewer. – migueaguilera Jul 20 '21 at 15:31
  • Excuse me @cyrille: I'm trying to decompress the output_db.idx file with no luck because it doesn't appear to be in gzip format. Could you give me some tips to access the content of the file? – migueaguilera Jul 21 '21 at 11:48
  • @migueaguilera - my apologizes for this, I had a defect in the d/l code - I pushed a fix online, so please try again. I also added a new command to decode the idx(.gz) file - try ./forge.js decode-svf2-idmap output_dbid.idx.gz or /forge.js decode-svf2-idmap output_dbid.idx – cyrille Jul 23 '21 at 08:10
  • Thanks @cyrille, I tested your code and now it works fine. Another question: all the models I am testing have "outputType": "svf" and "overrideOutputType": "svf2" in the manifest, but I noticed that the id mapping of svf2 is only needed in some of them (I think they are those models that were most recently uploaded to BIM 360 Docs). Is there any other field value to check in the JSON manifest to determine in which cases the id mapping is required? – migueaguilera Jul 25 '21 at 09:17
  • that's odd, but you right - these models might be the ones used during the OTG alpha. Can you contact me at cyrille at autodeslk.com - I'd like to debug this with you. – cyrille Jul 26 '21 at 07:47