Производный перевод моделей Revit, хранящихся в документах BIM360 - PullRequest
0 голосов
/ 01 ноября 2019

Я работаю над приложением для преобразования моделей 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'

1 Ответ

0 голосов
/ 01 ноября 2019

означает необходимость загрузки одного и того же файла дважды (один раз с конечной точки API управления данными на сервер, затем с сервера на клиент). Это проблематично для больших моделей.

Попробуйте настроить прокси-сервис в своем бэкэнде для ретрансляции пользовательских запросов и указания им загружать производные и вставлять токены в свои заголовки, чтобы токены не отображалиськлиентам, поэтому файлы не должны будут физически помещаться на ваш бэкэнд в качестве посредника - см. здесь для примера.

Обновим этот ответ, как только мы дойдем до концапервый выпуск.

...