'How to get a list of nested links for a Revit model using Forge APIs
I can acquire the full list of nested links in a Revit model using Revit APIs by this query:
FilteredElementCollector collector = new FilteredElementCollector(document);
return collector.OfCategory(BuiltInCategory.OST_RvtLinks)
.OfClass(typeof(RevitLinkInstance))
.Cast<RevitLinkInstance>()
.Select(linkInstance => document.GetElement(linkInstance.GetTypeId()) as RevitLinkType)
.Where(revitLinkType => revitLinkType.IsNestedLink)
.Select(type => type.Name)
.Distinct()
.ToList();
I am trying to replicate the same function using Forge APIs. While I can't get the nested links directly, I am hoping to get it in two steps.
First: acquire the list of linked docs, Second: query the linked docs on every linked document acquired in step one.
I am using this API to get the list of linked docs for step one:
'https://developer.api.autodesk.com/data/v1/projects/[project_id]/versions/[version_id]/relationships/refs'
That returns a list that includes: linked docs, the document itself, and any document that has the document linked in. So for example:
If A links B, and B links C, When I call the API on B, I get A, B and C. Now, it's easy to eliminate B from the response, but it's a bit confusing to figure out between A and C which one is a linked document.
I checked all the attributes and couldn't find anything, is there something I am missing? Also, is this the best way to acquire the list of nested linked documents?
Solution 1:[1]
Thanks for the response Eason. Ok so if I use the 'GET' equivalent it works as you described. However, I can only get it to work on smaller test models, the API simply returns an empty array for data, even though the project does have several linked document:
{
"jsonapi": {
"version": "1.0"
},
"links": {
"self": {
"href": "https://developer.api.autodesk.com/data/v1/projects/b.19e2199f-4132-4c47-9972-37d4708ea59f/versions/urn:adsk.wipprod:fs.file:vf.ZhP9FgAOTx6T4EV8acbrJg%3Fversion=27/relationships/refs"
},
"related": {
"href": "https://developer.api.autodesk.com/data/v1/projects/b.19e2199f-4132-4c47-9972-37d4708ea59f/versions/urn:adsk.wipprod:fs.file:vf.ZhP9FgAOTx6T4EV8acbrJg%3Fversion=27/refs"
}
},
"data": []
}
Are there any limits for this API? Why would this work on some models and not on the other ones?
Solution 2:[2]
To identify which file is the host or link, we can take a look at the direction attribute of the responses of GET projects/:project_id/versions/:version_id/relationships/refs
Here are two example responses representing the host and link correspondingly.
//Host Model
"data": [
{
"type": "versions",
"id": "urn:adsk.wipprod:fs.file:vf.n4QEQGINSWid8VvcBVds1w?version=1",
"meta": {
"refType": "xrefs",
"fromId": "urn:adsk.wipprod:fs.file:vf.n4QEQGINSWid8VvcBVds1w?version=1",
"fromType": "versions",
"toId": "urn:adsk.wipprod:fs.file:vf.y6GJ2scBSVSyIRM_wtEsDA?version=1",
"toType": "versions",
"direction": "to",
"extension": {
"type": "xrefs:autodesk.core:Xref",
"version": "1.1",
"schema": {
"href": "https://developer.api.autodesk.com/schema/v1/versions/xrefs:autodesk.core:Xref-1.1"
},
"data": {
"nestedType": "overlay"
}
}
}
}
],
// Link model
"data": [
{
"type": "versions",
"id": "urn:adsk.wipprod:fs.file:vf.y6GJ2scBSVSyIRM_wtEsDA?version=1",
"meta": {
"refType": "xrefs",
"fromId": "urn:adsk.wipprod:fs.file:vf.n4QEQGINSWid8VvcBVds1w?version=1",
"fromType": "versions",
"toId": "urn:adsk.wipprod:fs.file:vf.y6GJ2scBSVSyIRM_wtEsDA?version=1",
"toType": "versions",
"direction": "from",
"extension": {
"type": "xrefs:autodesk.core:Xref",
"version": "1.1",
"schema": {
"href": "https://developer.api.autodesk.com/schema/v1/versions/xrefs:autodesk.core:Xref-1.1"
},
"data": {
"nestedType": "overlay"
}
}
}
}
],
The direction attribute has two possible values, one is to and another is from.
In the above example, host urn:adsk.wipprod:fs.file:vf.n4QEQGINSWid8VvcBVds1w?version=1 is linked to urn:adsk.wipprod:fs.file:vf.y6GJ2scBSVSyIRM_wtEsDA?version=1. Consider it like an arrow with the head pointing to-wards the link model.
What you see from link model perspective is simply the reverse, the arrow is coming from the host urn:adsk.wipprod:fs.file:vf.n4QEQGINSWid8VvcBVds1w?version=1.
In both example responses, the fromId and toId don't change, only the direction of the arrow depending from which perspective you're looking at.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Ehsan Barekati |
| Solution 2 |
