Lavorare con le coordinate in Revit (e Dynamo)

Continuo con la serie di tutorial e questa settimana abbiamo l’opportunità di affrontare l’integrazione tra BIM e GIS, per lo meno di striscio e almeno per quanto riguarda l’integrazione tra il file di progetto e il contesto georeferenziato. Parliamo di geometria, in questo caso, e non dei dati che ci vengono dai sistemi informativi territoriali, […]

Continuo con la serie di tutorial e questa settimana abbiamo l’opportunità di affrontare l’integrazione tra BIM e GIS, per lo meno di striscio e almeno per quanto riguarda l’integrazione tra il file di progetto e il contesto georeferenziato. Parliamo di geometria, in questo caso, e non dei dati che ci vengono dai sistemi informativi territoriali, ma è già qualcosa (e la parte informativa avrebbe bisogno di tutto un discorso a parte). Vediamo quindi alcuni workflow possibili, con l’aiuto di Dynamo, di qualche plug-in e di una buona dose di pensiero laterale.

1. Importare Revit in Google Earth

Il workflow è possibile grazie ad un paio di trucchetti: la possibilità di esportare un file RVT in formato .dae e la possibilità di sfruttare Google Earth PRO, recentemente diventato gratuito e scaricabile da qui. Per esportare in .dae, invece, esistono un paio di opzioni possibili tra quelle gratuite:

Le altre opzioni a disposizione mi sembrano risibilmente costose.
Non amo particolarmente Lumion come software di rendering in tempo reale, ma per questo workflow userò il loro exporter, che funziona molto bene.

Una volta esportato il modello Revit in formato .dae, si può importare in Google Earth come modello. Quando il file .dae è stato aperto, si può raggruppare in un sub-folder, aggiungere i segnalibri, . Se volete fare dei test senza esportare un modello da Revit, potete provare con qualcuno dei file che trovate a questo indirizzo. Attenzione perché non tutti i modelli vengono supportati da Google Earth (ad esempio, questo progetto non è adatto).

COLLADA (COLLAborative Design Activity) is an interchange file format for interactive 3D applications. It is managed by the nonprofit technology consortium, the Khronos Group, and has been adopted by ISO as a publicly available specification, ISO/PAS 17506.

Bisogna quindi aprire il file formato dae (per la prima volta consiglio di aprirlo e non di importarlo, come viene detto su RevitCity, mentre consiglio di importare eventuali ulteriori .dae parti di un eventuale modello federato). Una volta aperto, ci si troverà di fronte al pannello di creazione del nuovo modello, in cui si potranno modificare le informazioni collegate e le coordinate.

. .

Una volta terminato di arricchire il progetto con le informazioni necessarie, si può salvare in .kmz e inviare a chi di dovere, che potrà aprirlo e consultare gli eventuali markup.

Onore al merito di questo procedimento va a chi l’ha condiviso su RevitCity.

2. Esportare verso Google Earth da Navisworks

Anche Navisworks ha un plug-in per Google Earth, che consente di esportare direttamente in formato KML (Keyhole Markup Language, documentato a questo indirizzo): trovate un tutorial qui. Le opzioni anche in questo caso riguardano le coordinate, l’uso di un eventuale secondo e terzo punto di riferimento, il numero di poligoni.

L’opzione di collassare l’esportazione consente di scegliere tra:

  • None, che esporta tutta la gerarchia;
  • All Objects, che collassa tutti gli oggetti in un nodo;
  • Files, che collassa i singoli file del federato, ciascuno in un nodo;
  • Layers, che collassa per livello.

Sono workflow vecchissimi: guardate questa classe di Charles MacLean all’Autodesk University del 2012, quando non esistevano le masse concettuali e ancora si parlava di Project Vasari come da vivo.


3. Il workflow inverso: entrare in Revit

Per esportare, quindi, ci sono un paio di opzioni valide a portata di mano. Ma sarebbe anche il caso che ci si guardi intorno mentre si sviluppa il progetto e non sempre si ha a disposizione un rilievo vero e proprio, soprattutto nelle fasi iniziali del progetto (nonostante la ISO 19650 dichiari senza mezzi termini che il cliente, insieme agli Information Requirements, debba mettere a disposizione il modello dello stato dei luoghi).

Per collegare uno stato di fatto messo pubblicamente a disposizione, una volta esisteva un plug-in chiamato Globe Link, che da diversi anni non viene più messo a disposizione né tramite la subscription né separatamente. Al suo posto si trovano Ge-Terrain, che costa una trentina di dollari e converte i contenuti di Google Map in file dwg. Per i workflow con AutoCAD, non posso però che rimandarvi a questo eccellente articolo di Gimmi GIS.

3.1. Dove siamo?

La prima cosa che dovremmo cercare di capire è dove siamo. Dove stiamo andando forse no, o per lo meno non basta un tutorial, ma almeno dove siamo.
In Revit esistono due modi di specificare dove siamo, e devono essere applicati entrambi perché alcune funzionalità guardano una cosa mentre altre ne guardano un’altra. No, non è ben chiaro perché.

Il primo modo di specificare dove siamo è la georeferenziazione del cosiddetto Survey Point, quel triangolino che di default si trova sopra al Project Base Point quando iniziate un progetto.

Se parte del vostro rilievo è un DWG realizzato in Civil3D e correttamente georeferenziato, potete usare il workflow di acquisizione delle coordinate dal DWG per posizionare correttamente il Survey Point usando lo Shared Reference Point Tool (solo scaricabile dall’account Autodesk a partire dalla versione 2018). Attenzione perché c’è un’ottima possibilità che nel farlo rompiate le coordinate nel file di Civil3D, ma questa è un’altra storia.

Qualunque sia il metodo che avete scelto, la lettura del Survey Point è diversa dalla lettura delle impostazioni che si trovano sotto a Manage -> Location. La prima è la georeferenziazione vera e propria, mentre la seconda influisce su cose come lo studio delle ombre. Perché ce ne sono due? Perché mai dovrebbero essere diverse? Chiedetelo ad Autodesk.

In ogni caso, all’interno di Dynamo esistono due nodi abbastanza simili per interrogare la Location di un modello: il primo è Document.Location e ci consente di interrogare qualunque file, ottenendone Latitudine e Longitudine. Non sappiamo ancora dove siamo (ne parleremo più avanti) ma è già qualcosa.

Un nodo un pochino più gentile è SiteLocation, che oltre a latitudine e longitudine ci restituisce anche l’indirizzo (l’operazione di trasformare delle coordinate in un indirizzo si chiama Reverse Geocoding e ci sono diversi servizi on-line che possono essere invocati per farlo.

Scopriamo così che il template architettonico è a Londra.

Abbiamo quindi un nodo sintetico e un nodo un pochino più prolisso, ma ancora un po’ troppo discorsivo. Se dobbiamo lavorare con le coordinate, consiglio di installare il package GIS2BIM di Maarten Vroegindeweij, che contiene una serie di utilissime funzioni. La prima è proprio quella di spacchettare la Location in tutte le informazioni di cui potremmo avere bisogno, pronte per l’utilizzo. Il lavoro viene fatto dal nodo GIS2BIM_GetRevitSiteLocation.

Grazie, Maarten

Molti dei nodi di GIS2BIM si “limitano” a impacchettare in una funzione una serie di operazioni di traslazione geometrica o, come in questo caso, una serie di operazioni sulle stringhe. Se apriamo il nodo e vediamo quello che c’è dentro, ci rendiamo conto che non c’è programmazione: solo la capacità di guardare ciò che Revit ci restituisce e di organizzarlo come ci serve.

Questo è l’interno del nodo custom GIS2BIM_GetRevitSiteLocation. L’ho aperto e raggruppato per farvelo vedere meglio: voi non fatelo.

Andando a vedere se è vero, vedremo che effettivamente tutti questi nodi hanno ragione: un file creato con il template architettonico si posiziona di default a Londra, quasi a Charing Cross.

Se siete come me, a questo punto non potete non andare a fare una verifica importante: cosa diavolo c’è in Whitehall 16, Westminster, Londra?

-0.127210, 51.506420

Il template architettonico di Revit è nato al Pub. Questo spiega un sacco di cose.

3.2. E se ho solo l’indirizzo?

Come accennavo, la procedura di ricavare coordinate da un indirizzo viene chiamata Reverse Geocoding e ci sono svariati servizi on-line che se ne occupano. Nel package GIS2BIM esiste anche un nodo specifico che si chiama GIS2BIM.GeocodingNormatimAPI, che fa leva sulla API omonima di Open Street Map.

Il nodo richiede delle stringhe, analoghe a quelle che ci restituiva GetRevitSiteLocation:

  • il nome della strada;
  • il numero;
  • la città;
  • la nazione.

3.3. Il Survey Point

Il Survey Point, invece, non si è mosso di un millimetro. Si trova ancora lì, piantato nel mezzo del modello vuoto, su 0,0,0. Possiamo verificarlo accendendo il Survey Point che, se ricordate, ha una sottocategoria tutta per sé al di sotto della categoria Site (un’informazione che ci tornerà comoda tra poco, quando proveremo ad acchiapparli con Dynamo).

Eccoli lì, i due bastardi.

Come immaginavamo, il Survey Point non è posizionato nel rispetto della location, per via di quei due modi in cui si può utilizzare il punto, almeno stando a sentire Autodesk.

Il modello è un modello quantico: siamo contemporaneamente al pub a Londra e nel Golfo di Guinea, all’incrocio tra l’Equatore e il meridiano di Greenwich.

Per l’amor del cielo, non è male, eh?

Per andare a pescare il Survey Point, abbiamo solo bisogno di ricordare cosa abbiamo fatto per accenderlo: il Survey Point, per motivi che sono conosciuti solo alla mente contorta che l’ha inserito nel codice di Revit, ha una propria categoria ed è l’unico elemento della propria categoria. Un semplice Categories -> All Elements of Category ce lo restituisce quindi, pulito, semplice, apparentemente innocente. Se è un elemento come tutti gli altri, i suoi parametri possono essere elencati semplicemente con Element.Parameters.

Le coordinate che ci interessano sono all’indice 3 (E/W), all’indice 8 (N/S), se vogliamo lavorare come Google, oppure all’indice 6 e 7 (Latitudine e Longitudine) se, come probabilmente sarà, preferiamo ragionare nello stesso modo della Location del documento.

Se ricordate però, spostare un Survey Point con la pin attivata è ben diverso da spostarlo senza pin. Se non ce lo ricordiamo, basta fare un paio di prove (magari modellando una banana con riferimento chiaro al Project Base Point).

Spostando il Survey Point con la clip attiva…

…le coordinate del Survey Point non sono cambiate e il modello non si è spostato.

Il Project Base Point ha acquisito coordinate come se il Survey Point fosse l’origine del mondo.

Ergo, sposto il Survey Point sparandolo al largo del Golfo di Guinea, insieme ai delfini, per avere il Project Base Point con le coordinate giuste.

Se disattivo la clip, non succede nulla: il Project Base Point continua a dichiarare le sue coordinate, il Survey Point continua a essere convinto di essere a fare il bagno.

Se però lo sposto di nuovo, mentre la clip è disattivata, succede qualcosa di curioso: il Project Base Point continua a dichiarare le proprie cordinate, e anche il Survey Point si mette a dichiarare delle coordinate che fanno ancora riferimento al punto in cui l’ho posizionato prima, quando la sua clip era attiva.

Bel casino…

Se per caso cambio idea, e attivo nuovamente la clip al Survey Point, di nuovo non cambia nulla: il Survey Point continua a dichiarare quelle coordinate buffe e, se lo riporto all’incrocio dei due piani di riferimento dov’era prima, sto ridefinendo un offset rispetto al sistema di coordinate di prima, quindi quel punto non è più l’origine.

Spostato con la clip attiva…
…ed ecco che nssuno capisce più nulla di quello che sta succedendo.

Esiste quindi un’altra informazione importantissima, di cui dobbiamo occuparci prima di iniziare a spostare Survey Point come se non ci fosse un domani, perché altrimenti non ci sarà un domani. Devo verificare lo status del Survey Point, ovvero se sia o meno attiva la pin. Esiste un nodo specifico che fa questa domanda agli elementi, Element.IsPinned, e restituisce un valore booleano (funziona con qualunque elemento del modello).

Attenzione però, perché usando il nodo rovescio con una booleana = True a Element.SetPinnedStatus, ci rendiamo conto che lo status di pinnato è diverso dallo status di clippato e lo status di clippato non appare da nessuna parte.

Così è pinnato e clippato… e poi? Stampiamo in pdf e plastifichiamo la stampa?

 

In virtù di quanto abbiamo appena visto, dobbiamo spostare il Survey Point pinnato per fare in modo di ereditare, nel Project Base Point, le coordinate riferite a quel punto.

Ma anche questa operazione può riservare delle sorprese perché, come viene spiegato in questo articolo, Dynamo vede le coordinate del Survey Point esattamente come Revit, e non come ce le aspettiamo noi, e può agire su di esse solo quando il Survey Point non ha la pin attivata.

Inoltre, Latitude e Longitude sono parametri read-only, non possiamo editarli. Bisogna quindi trasformare Lat e Lon in Easting e Northing, ad esempio in questo modo.

Spariamo quindi il Survey Point secondo quelle coordinate e, pinnandolo, ciò che otteniamo è che il Project Base Point erediterà quel riferimento e sarà quindi referenziato correttamente.

Sto usando il nodo ʳʰʸᵗʰᵐ|Elements.SetParameterByNameTypeOrInstance in modo da non dovermi preoccupare se quella roba sia un parametro di istanza o di tipo.

Non ho trovato nulla di valido per spostare il punto, e se state pensando a Element.SetLocation ricordate che funziona solo sugli elementi strutturali.

Idee?

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.