Я работаю над приложением для преобразования моделей Revit, которые уже были опубликованы в облаке, в формат IFC с использованием API-интерфейсов управления данными и производных моделей, и столкнулся с двумя ключевыми проблемами для API-интерфейса, производного от модели.
1. Ошибка перевода на основе модели:
Я столкнулся с ошибкой перевода, которая также возникла в других потоках Ошибка загрузки модели Файл не является файлом Revitили не поддерживается версия
code:"Revit-UnsupportedFileType"
message:"<message>The file is not a Revit file or is not a supported version.</message>"
type:"error"
code:"TranslationWorker-RecoverableInternalFailure"
message:"Possibly recoverable warning exit code from extractor: -536870935"
type:"error
Однако мой случай несколько уникален, и другие ответы не применимы. Предыдущие случаи потерпели неудачу из-за неправильной версии Revit (очевидно, перевод может работать в версии 2016 года, но не версии 2019) или из-за повреждения при загрузке файла. Это не может быть применимо для меня, так как перевод .rvt в .svf был успешным для этой модели, только мой перевод .rvt в .ifc не удался, также я не загружаю через приложение, а обращаюсь к файлам, которые уже есть в документах BIM360.
Другая странная часть этого поведения заключается в том, что перевод .rvt ->. Ifc был успешным для более ранних версий той же модели. Это наводит меня на мысль, что, возможно, существует проблема с размером файла, когда последняя версия модели слишком велика для перевода, хотя я не нашел никаких ограничений на размер файла в документации по производной модели.
2. Проблема загрузки производной модели:
Маршрутизация загрузки переведенного файла через мой сервер перед повторной загрузкой с сервера на клиент, чтобы использовать 3-сторонний токен OAuth, означает необходимость загрузить тот же самыйфайл дважды (один раз с конечной точки API управления данными на сервер, второй - с сервера на клиент). Это проблематично для больших моделей. В настоящее время мое решение состояло в том, чтобы просто передать 3-х сторонний токен OAuth и URI файла клиенту и передать запрос напрямую от клиента к конечной точке Autodesk, хотя я думал, что это плохая практика.
Я не нашеллюбые образцы, которые включают эту конечную точку загрузки, NodeJS, были бы оптимальными для меня. Также мне бы хотелось, чтобы к конечной точке был присоединен заголовок длины содержимого, чтобы дать лучшее представление о ходе загрузки.
Соответствующие конечные точки для моих проблем находятся здесь: https://forge.autodesk.com/en/docs/model-derivative/v2/tutorials/translate-source-file-to-obj/
Перевести:
curl -X 'POST' -H 'Authorization: Bearer WmzXZq9MATYyfrnOFpYOE75sL5dh' -H 'Content-Type: application/json' -v 'https://developer.api.autodesk.com/modelderivative/v2/designdata/job' -d
'{
"input": {
"urn": "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ"
},
"output": {
"formats": [
{
"type": "obj"
}
]
}
}'
Примечание: я использовал «type»: ifc вместо «type»: obj, в качестве выходного формата для этой конечной точки;это не проблема.
Проверка:
curl -X 'GET' -H 'Authorization: Bearer RWLzh098vuF3068r73FI7nF2RORf' -v 'https://developer.api.autodesk.com/modelderivative/v2/designdata/dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ/manifest'
Загрузка:
curl -X 'GET' -H 'Authorization: Bearer RWLzh098vuF3068r73FI7nF2RORf' -v 'https://developer.api.autodesk.com/modelderivative/v2/designdata/dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ/manifest/urn%3Aadsk.viewing%3Afs.file%3AdXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bW9kZWxkZXJpdmF0aXZlL0E1LmlhbQ%2Foutput%2Fgeometry%2Fbc3339b2-73cd-4fba-9cb3-15363703a354.obj'