{"id":31672,"date":"2020-05-13T07:16:38","date_gmt":"2020-05-13T06:16:38","guid":{"rendered":"https:\/\/mascalagrimas.es\/dev-msi_old\/?p=31672"},"modified":"2020-05-13T07:16:38","modified_gmt":"2020-05-13T06:16:38","slug":"que-es-un-modelo-unico-de-documentacion","status":"publish","type":"post","link":"https:\/\/mascalagrimas.es\/dev-msi_old\/que-es-un-modelo-unico-de-documentacion\/","title":{"rendered":"\u00bfQu\u00e9 es un modelo \u00fanico de documentaci\u00f3n?"},"content":{"rendered":"\n

Cuando se trabaja en un proyecto con Revit<\/strong>,\nes com\u00fan dividir el edificio en distintos archivos<\/strong>. De este modo se\nconsigue no concentrar toda la informaci\u00f3n<\/strong> en un \u00fanico modelo<\/strong> que\nresultar\u00eda demasiado pesado como para trabajar c\u00f3modamente en \u00e9l.<\/p>\n\n\n\n

En funci\u00f3n de las necesidades requeridas en un\nproyecto, se pude estructurar el trabajo y el desarrollo de un proyecto BIM<\/strong>\nde varias maneras. Un criterio que se puede seguir para desarrollar los archivos\nde un proyecto es plantear los modelos siguiendo las distintas disciplinas<\/strong>\nexistentes, dando como resultado un archivo de arquitectura (ARQ), uno de\nestructuras (STR) y otro de instalaciones (MEP). <\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 1. Ejemplo de distintos archivos incluyendo el de documentaci\u00f3n. Fuente propia.<\/figcaption><\/figure><\/div>\n\n\n\n

Estos archivos se van desarrollando paralelamente entre s\u00ed hasta que llega el momento de documentar<\/strong> el proyecto. Llegados a este punto muchas personas se preguntan qu\u00e9 es mejor, \u00bfobtener todos los planos<\/strong> de los distintos archivos o generar un cuarto archivo de Revit (DOC) donde generar y gestionar las tablas<\/strong>, planos<\/strong>, im\u00e1genes<\/strong>, leyendas<\/strong>, etc. de un proyecto?<\/p>\n\n\n\n

Funcionamiento<\/h2>\n\n\n\n

El funcionamiento de un archivo \u00fanico de\ndocumentaci\u00f3n<\/strong> es sencillo. La forma de trabajar en \u00e9l es el mismo que en un\narchivo est\u00e1ndar con v\u00ednculos<\/strong> de otras disciplinas s\u00f3lo que en este\ncaso, por lo general, no existir\u00e1 ning\u00fan elemento modelado y todas las labores\nde documentaci\u00f3n se realizar\u00e1n sobre los modelos vinculados de arquitectura,\nestructuras e instalaciones.<\/p>\n\n\n\n

La idea es agrupar toda la informaci\u00f3n del\nmodelo en un \u00fanico archivo donde se encuentren todos los planos de las\ndistintas disciplinas, las vistas gr\u00e1ficas (plantas, secciones, 3D, etc.),\ntablas de planificaci\u00f3n, leyendas, todos los tipos de elementos gr\u00e1ficos como\nl\u00edneas o textos, familias de anotaci\u00f3n, im\u00e1genes y evidentemente los v\u00ednculos.<\/p>\n\n\n\n

Es por eso que en este tipo de modelos se debe\ntener un gran control sobre los v\u00ednculos (Insertar>Gestionar v\u00ednculos) y\nsobre el visualizador de gr\u00e1ficos<\/strong>. Es posible que la visualizaci\u00f3n de\nciertos elementos cambie dependiendo de en qu\u00e9 v\u00ednculo se encuentre con lo que\nes muy probable que cada v\u00ednculo tenga su propio visualizador de gr\u00e1ficos personalizado<\/strong>.<\/p>\n\n\n\n

\"\"
Ilustraci\u00f3n 2. Paleta de control del visualizador de gr\u00e1ficos para v\u00ednculos. Fuente propia. <\/figcaption><\/figure><\/div>\n\n\n\n

Sin embargo, no se podr\u00e1 generar ninguna vista\nsi previamente no se han generado niveles<\/strong>. Para este tipo de elementos\n(niveles, rejillas, etc.) lo m\u00e1s recomendable es utilizar la herramienta \u201cCopiar\ny monitorizar<\/strong>\u201d para contar con los mismos elementos de referencia que los\narchivos que contienen los modelos y adem\u00e1s ser avisados si alguno de ellos\ncambia o se suprime.<\/p>\n\n\n\n

Pros y contras<\/h2>\n\n\n\n

El principal objetivo\ncuando se recurre a esta soluci\u00f3n es mejorar el rendimiento<\/strong> ya no solo\ndel modelo, sino tambi\u00e9n el del ordenador. <\/p>\n\n\n\n

Es bien sabido que,\na m\u00e1s elementos en un modelo, peor rendimiento. Cuantas veces nos hemos\nencontrado modelos donde es pr\u00e1cticamente imposible orbitar<\/strong> alrededor\ndel edificio o donde se ejecuta alguna herramienta y debemos esperar varios minutos\nhasta que se cumple la orden. Incluso puede darse el caso en el que no sea\nposible contar con un ordenador suficientemente potente para trabajar con\nprogramas tan exigentes como los de modelado BIM. Todos estos problemas pueden\nresultar especialmente molestos en fases de documentaci\u00f3n donde constantemente\nse est\u00e1n a\u00f1adiendo elementos como cotas<\/strong>, textos<\/strong>, etiquetas<\/strong>,\netc. Separar la documentaci\u00f3n de los modelos afecta directamente al rendimiento\ndel ordenador, el cual consumir\u00e1 menos recursos y funcionar\u00e1 mejor. <\/p>\n\n\n\n

Trabajar con un modelo \u00fanico de documentaci\u00f3n\ntambi\u00e9n permite definir responsabilidades<\/strong> con m\u00e1s claridad dentro de un\nproyecto. En algunos casos hemos podido ver equipos que externalizan el trabajo de documentaci\u00f3n y que, al tener un modelo\na parte y \u00fanico, evitaba los cl\u00e1sicos problemas que pueden aparecer flujos de\ntrabajo est\u00e1ndar donde se pueden llegar a eliminar o editar elementos del\nmodelo. De esta manera tambi\u00e9n se consigue tener toda la documentaci\u00f3n del\nproyecto concentrada en un \u00fanico modelo y no dividida en varios.<\/p>\n\n\n\n

El problema lo\npodemos encontrar en proyectos muy grandes, donde ya de por s\u00ed hay varios\nmodelos de cada disciplina y se pueden complicar las labores de gesti\u00f3n<\/strong>\nde estos. Adem\u00e1s, cualquier cambio que se precise en los modelos se deber\u00e1n\nhacer desde sus respectivos archivos, con lo cual, si se detectase alg\u00fan error,\nse deber\u00eda cerrar el archivo de documentaci\u00f3n o descargar<\/strong> el link, para\nabrir el archivo que contenga el modelo y cambiarlo.<\/p>\n\n\n\n

\"Cuadro
Ilustraci\u00f3n 3. Paleta de control de v\u00ednculos. Fuente propia.<\/figcaption><\/figure><\/div>\n\n\n\n

Por lo general si\nun vinculo se descarga del archivo de documentaci\u00f3n y ya hay cotas o etiquetas\ncolocadas, estas no se pierden siempre que se vuelva a cargar este mediante las\nopciones \u201cvolver a cargar\u201d o \u201cvolver a cargar desde\u201d, pero hay que tener en\ncuenta que estos archivos son m\u00e1s sensibles a cambios y si que se puede llegar\na perder alguna informaci\u00f3n y m\u00e1s a\u00fan en casos en que los modelos siguen vivos\ny se est\u00e1n editando al mismo tiempo que se genera la documentaci\u00f3n.<\/p>\n\n\n\n

 En\ncualquier caso, si que se eliminaran las etiquetas o las cotas que hagan\nreferencia a un elemento el cual ha modificado su ID<\/strong>. Esto puede darse\ncuando un elemento se elimina<\/strong> o se \u201cremodela<\/strong>\u201d. Por eso es\nimportante que los equipos de modelado y documentaci\u00f3n est\u00e9n bien coordinados\nentre s\u00ed y entiendan que un elemento que ya est\u00e1 acotado o etiquetado en el\narchivo de documentaci\u00f3n no se debe suprimir si se quiere modificar, siempre\nser\u00e1 mejor editarlo.<\/p>\n\n\n\n

Por otro lado, se debe preparar muy bien el\nvisualizador de gr\u00e1ficos y hacer uso de los filtros de vista<\/strong>. Es com\u00fan\nque estos modelos cuenten con un gran n\u00famero de filtros de vista para modificar\nel grafismo de los distintos elementos puesto que no solo basta con configurar\nla visualizaci\u00f3n de gr\u00e1ficos de los v\u00ednculos como \u201cpersonalizado\u201d. Esto puede\nsuponer un problema cuando al modelo acceden personas que no conocen bien el\nfuncionamiento de este, y generan m\u00e1s filtros o editan la configuraci\u00f3n cuando\nrealmente no es necesario. Esto puede afectar a plantillas de vista<\/strong> o a\nconfiguraciones que ya estaban establecidas de una manera determinada y que den\ncomo resultado vistas de entrega defectuosas.<\/p>\n\n\n\n

Por \u00faltimo, hay que tener presente que los\nv\u00ednculos entre s\u00ed no se pueden unir<\/strong>, y que en el caso de distintos\nv\u00ednculos que muestren elementos que deban estar unidos entre s\u00ed, se deber\u00e1\npensar alguna soluci\u00f3n para disimular las juntas que se generar\u00e1n mediante regiones\nrellenadas<\/strong>, de m\u00e1scara<\/strong> o similares.<\/p>\n\n\n\n

\"Cuadro
Ilustraci\u00f3n 4. Ejemplo de soluci\u00f3n de uniones entre v\u00ednculos. Fuente propia.<\/figcaption><\/figure><\/div>\n\n\n\n

Conclusi\u00f3n<\/h2>\n\n\n\n

Para resolver la pregunta que nos hac\u00edamos al principio, no podemos decir que una opci\u00f3n sea mejor que otra. Realmente, como todo en este mundo del BIM<\/strong> y el Revit, depende de la estrategia<\/strong> que sigamos o de los criterios<\/strong> establecidos en el contrato. Lo importante en situaciones como estas es pensar bien cuales van a ser nuestras necesidades y qu\u00e9 es lo que necesitamos obtener del modelo o del proyecto.<\/p>\n\n\n\n

En MSI\nparticularmente preferimos homogeneizar los elementos necesarios para obtener\ndocumentaci\u00f3n como cotas, car\u00e1tulas, textos y dem\u00e1s, y obtener la informaci\u00f3n\ngr\u00e1fica directamente de los modelos correspondientes siempre que sea posible. A\npesar de esto, creemos que siempre es necesario analizar las condiciones del\nproyecto y buscar la soluci\u00f3n m\u00e1s optima.<\/p>\n\n\n\n

Si optamos por homogeneizar los archivos y en el\ncaso de necesitar planos en com\u00fan como el \u00edndice, hacemos uso de la herramienta\nInsertar vista desde archivo<\/strong> (Insertar>Insertar desde\narchivo>Insertar vista desde archivo) para as\u00ed insertar los planos de los\ndem\u00e1s v\u00ednculos. Esto permite tener el plano y los elementos contenidos en \u00e9l,\ncomo vistas, tablas, leyendas, etc.<\/p>\n","protected":false},"excerpt":{"rendered":"

Cuando se trabaja en un proyecto con Revit, es com\u00fan dividir el edificio en distintos archivos. De este modo se consigue no concentrar toda la informaci\u00f3n en un \u00fanico modelo que resultar\u00eda demasiado pesado como para trabajar c\u00f3modamente en \u00e9l. En funci\u00f3n de las necesidades requeridas en un proyecto, se pude estructurar el trabajo y… Seguir leyendo \u00bfQu\u00e9 es un modelo \u00fanico de documentaci\u00f3n?<\/span><\/a><\/p>\n","protected":false},"author":6,"featured_media":31678,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"rank_math_lock_modified_date":false,"_joinchat":[],"footnotes":""},"categories":[5],"tags":[129,130,131,22,132,133],"class_list":["post-31672","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-consultoria","tag-disciplinas","tag-documentacion","tag-planos","tag-revit","tag-vinculos","tag-visualizacion","entry"],"acf":[],"_links":{"self":[{"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/posts\/31672"}],"collection":[{"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/comments?post=31672"}],"version-history":[{"count":0,"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/posts\/31672\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/media\/31678"}],"wp:attachment":[{"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/media?parent=31672"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/categories?post=31672"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mascalagrimas.es\/dev-msi_old\/wp-json\/wp\/v2\/tags?post=31672"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}