shelidonDecember 4, 20202 Comments on Lavorare con le mappe in Revit (e Dynamo)

Mercoledì scorso ho pubblicato una dissertazione sulle coordinate di Revit e abbiamo scoperto che il template architettonico di Revit è in un pub di Londra. Nulla di troppo sorprendente.

Essere nella posizione giusta però è solo l’inizio di una serie di workflow che possono consentirci di far comunicare un po’ meglio il nostro modello con il contesto di progetto.
Prima di farlo, però, c’è un altro paio di concetti che ci occorre rinfrescare.

1. CRS (Coordinate Reference Systems) e dove trovarle

La terra non è tonda: è un sasso storto. E quindi tutte le tecniche a nostra disposizione per misurare la distanza tra due punti sulla superficie di una sfera (già di per sé fallaci e approssimati trattandosi di una sfera) vengono miseramente a cadere quando si tratta di passare dalla sfera al geodeta (il solido orribile che si usa per approssimare la terra) e, ancora peggio, dal geodeta alla situazione reale.

Quando approssimiamo in modo geocentrico (un sistema uguale per tutti) l’approssimazione è grande: nelle zone dove il mondo è più pieno di bozzi, avremo un margine di errore più alto. Per questo, nascono sistemi di riferimento locali, che si creano il loro ellissoide e sono tutti contenti perché tra Rogoredo e Quarto Oggiaro le misurazioni sono più precise.

Esistono diversi modelli geodetici, alcuni con orientamento locale e altri validi globalmente. Il più popolare dei dati geodetici è il WGS84 (World Geodetic System), basato su un ellissoide sviluppato proprio nel 1984. Revit usa il sistema di coordinate LL84 basato su quel datum. Ulteriori informazioni si trovano nel tentativo di scambiare dati con Infraworks, qui e qui).

Il WGS è tanto carino, ma è approssimato da morire, quindi generalmente si usano sistemi di riferimento locali. Ciascuno di questi sistemi di riferimento è codificato con un numero EPSG (che ci servirà tra poco). Per trovare i propri sistemi di riferimento locali, consiglio questo sito.

Il WGS84 ha codice 4326, mentre la proiezione Web Mercator usata da Google Maps e Open Street Map ha codice 3857 (occhio perché pare cambi spesso). Il sistema globale ITRF2014, che dovrebbe essere utilizzato da tutti, ha codice 7789. In territorio europeo esiste una convenzione che vorrebbe si utilizzasse tutti l’European Terrestrial Reference System (ETRF89), che dovrebbe avere codice 7915. Per qualche motivo, sistemi locali come il vetusto e ormai superato per legge ROMA40 (Roma Monte Mario) continua a persistere e chissà quando riusciremo a liberarcene.

Dato che il sistema Monte Mario mi fa orrore, prendiamo un sistema di riferimento svizzero: il CH1903 / LV03 (che sarebbe il nome) con codice EPSG:21781.

Il package GIS2BIM che abbiamo utilizzato anche nello scorso tutorial ci offre un collegamento diretto a questo sito e lo interroga, dato un codice, per dirci se il sistema di riferimento che stiamo cercando di utilizzare è un sistema di riferimento valido oppure no. Il nodo si chiama GIS2BIM_SearchCRS e richiede in ingresso una semplice stringa.

Questa verifica ci serve perché uno dei nodi presenti all’interno di GIS2BIM ci consente di trasformare una coordinata da un sistema all’altro. Si tratta del nodo GIS2BIM_TransformCRS_epsg, che ha bisogno di sapere da dove partiamo (e di default dà per scontato che noi si parta dal 4326, ovvero dal WGS84, ovvero da qualcosa che abbiamo pescato da dentro a Revit) e dove vogliamo arrivare. A questo punto dovremo semplicemente dargli le coordinate X e Y (ad esempio la latitudine e la longitudine del nostro pub a Londra) e riceveremo in cambio le coordinate trasformate.

Ad esempio, se vogliamo provare a parlare con Google Maps l’EPS del nostro CRS (santissimo cielo) è 3857. Le differenze tra sistemi di coordinate possono essere piuttosto importanti (è il motivo per cui li abbiamo).

2. Eh vabbé, e quindi?

La trasformazione del sistema di coordinate è la prima cosa che ci serve per invocare un WMS.

WMS sta per Web Map service ed è uno standard messo a disposizione da Open Geospatial Consortium per scaricare mappe in formato raster.

Per farlo però dobbiamo creare una BoundingBox intorno allo spazio che ci interessa. E per farlo dobbiamo comunicare le coordinate di questa bounding box al servizio che vogliamo utilizzare, nel sistema di coordinate richiesto da quel servizio.

2.1. Definire lo spazio in Revit

Ipotizziamo di avere chiara l’area di mappa che vogliamo inserire all’interno di Revit e ipotizziamo di averla indicata all’interno del modello con un elemento di qualche tipo (meglio se di modello). Considerando di averlo fatto tramite una Model Line, possiamo estrarla e portarcela all’interno di Dynamo normalmente, pescando le Model Lines nel nodo Element Types, raccogliendole tutte con All Elements of Type e chiedendone la geometria con Element.Geometry.

Una volta estratta la geometria delle linee (che, indovinate, è una linea) potremmo estrarre i quattro punti e usarne i due estremi per creare una Bounding Box, ma onestamente non vedo perché, dato che esiste un nodo fatto apposta per creare una Bounding Box intorno a una geometria. Bisogna solo ricordarsi di appiattire la lista di geometrie in modo da avere tutte le linee sullo stesso livello.

Sfortunatamente, il nodo che voglio usare per ottenere le mappe è un nodo di BIM2GIS che effettivamente vuole proprio creare la Bounding Box da solo. Questo perché di fatto dobbiamo ovviare a un piccolissimo problema: secondo Revit la terra è piatta, mentre noi dobbiamo proiettare la nostra bounding box sul sasso storto.

GIS2BIM offre due nodi per creare la Bounding Box ed entrambi richiedono come input il punto centrale e come ulteriori input le dimensioni di offset da quel punto.

Nel nostro caso quindi, e ipotizzando che il Survey Point non sia al centro dell’area di cui vogliamo estrarre una mappa, dobbiamo fare un po’ di lavoro sulla nostra Bounding Box e ci sono diversi modi di approcciarlo.

Tanto per cominciare, noi stiamo creando una Bounding Box tridimensionale intorno a una polilinea su un piano, e non c’è nessun bisogno di fare questa fatica. Potremmo quindi considerare di usare il nodo PolyCurve.MinBoundingBox che si trova nel package Ampersand.

Si tratta di un package che contiene utilissimi nodi per l’analisi della geometria, sviluppato da Colin McCrone. Ci restituirà un rettangolo (dotato di larghezza e altezza), i quattro punti d’angolo, il vettore dell’asse maggiore, il vettore dell’asse minore e l’area (di cui in questa istanza facciamo veramente poco, ma che in altre circostanze potrebbe tornare utile).

Ma naturalmente, come spesso accade, cose che nella vita sono sinonime non lo sono all’interno di Dynamo. Il Poligono è un oggetto astratto e può essere creato unendo i puntini e vedendo cosa apparirà (nel nostro caso, se siamo veramente sfortunati, una farfallina).

Ampersand fortunatamente restituisce i punti d’angolo in un ordine sensato ma, per verificare che effettivamente non sia comparsa una farfallina, potete posizionare il nodo Polygon.SelfIntersections e verificare che la lista sia vuota (ovvero che il poligono non sia auto-intersecante).

A questo punto abbiamo più o meno tutto quello che ci serve. Il nodo GIS2BIM.CreateBoundingBox richiede solo la coordinata X e Y del punto centrale (che abbiamo appena trovato) e le dimensioni della Bounding Box (ovvero la lunghezza dei vettori degli assi).

Attenzione perché questo metodo prevede che il punto centrale sia correttamente georeferenziato con X e Y che cadono all’interno del servizio nazionale che si userà per interrogare le mappe. Questo è il motivo per cui personalmente preferisco l’altro metodo.

L’altro metodo richiede che la location sia impostata correttamente e ignora allegramente il Survey Point (un po’ il contrario di quello che fa normalmente la gente).

L’output Bbox è nello stesso formato del nodo precedente e viene utilizzato all’interno delle Web Request che mandiamo al servizio della nazione in cui ci troviamo.

E da questo punto in poi, consiglio fortemente di far riferimento al tutorial che l’autore del package ha svolto a BILTeurope e che per un caso fortuito trovate anche a questo indirizzo (non ce l’ho messo io). Se ne occupa da pagina 16 a pagina 18.

La difficoltà di questa applicazione è la Webrequest vera e propria (che potrà essere invocata tramite il nodo Web Request di Dynamo oppure tramite il nodo GIS2BIM_webrequestWMS): si tratta di una concatenazione di stringhe, che restituisce un’immagine ma che deve essere composta a mano.

Attenzione perché consultando le specifiche del sito potremmo renderci conto che le coordinate sono da invocare in modo buffo. Per esempio, questo è quello che bisogna fare per parlare sloveno.

Qualunque sia il servizio scelto, qualunque sia il modo per concatenare la richiesta, consiglio di scriversi prima il testo in un file esterno e provare a incollarlo a mano nell’indirizzo di un browser. Se esce un’immagine, abbiamo fatto tutto giusto. In caso contrario… abbiamo sbagliato qualcosa. Attenzione perché se il risultato che otteniamo è un’immagine vuota, non abbiamo sbagliato nulla: semplicemente il servizio invocato non dispone di materiale catastale nella zona scelta.

In alternativa, se avete Rhythm, c’è l’utilissimo nodo che invia una stringa alla clipboard (un po’ come fare Ctrl+C… che però in Dynamo non si può fare).

L’indirizzo potrebbe andare benissimo. Tipo questo. O questo (stesso settore, layer diverso). Oppure potreste trovarvi davanti a una situazione tipo questa. Congratulazioni.

In ogni caso, se la Web Request funziona può essere inviata tramite Dynamo e ciò che otteniamo è un’immagine.

2.2. Ma devo comporla davvero a mano?

No, scherzavo: Maarten non è così sadico. GIS2BIM offre una serie di nodi che da soli creano l’url di invocazione del servizio, nelle diverse opzioni a disposizione, raggruppate per zona geografica, data una Bounding Box.

Questi ad esempio sono i servizi disponibili per l’Europa:

E questi sono due dei nodi in azione: quello che interroga la banca dati Scozzese (no, non si paga) e quella già utilizzata che interroga la banca dati Slovena.

2.3. Va bene, e adesso?

E adesso abbiamo un’immagine, in formato png. Bella. Cosa ci facciamo?

Potremmo essere tentati di salvarla come file esterno usando il nodo Image.WriteToFile…

…ma provandoci ci rendiamo immediatamente conto che il nodo ha bisogno di un’istanza, già posizionata nel modello, mentre noi abbiamo un’immagine che naviga nella cache del nostro Dynamo, per il momento. Qualunque dubbio può essere fugato andando a controllare se abbiamo immagini linkate nel nostro modello.

C’è un nodo specifico, nel package GIS2BIM, che salva esternamente l’immagine ricavata. Oppure potremmo salvarla dal browser e smetterla di essere pigri, come preferite.

Se il nodo non funziona, potrebbe essere che stiate usando il formato d’immagine sbagliato. Tenete presente che il nodo GIS2BIM_ImageToFile vuole un’immagine Jpeg come target. Come lo so? Ci ho guardato dentro.

Sempre nel package GIS2BIM esiste però anche la possibilità di inserire l’immagine in una vista, una volta salvata esternamente: si tratta del nodo GIS2BIM_ImportImageInView.

A questo punto bisogna fare due cose: impostare la scala della vista e ricordarsi qual era la larghezza della nostra immagine. Nel nostro caso, la larghezza è 300 metri, quindi l’immagine dev’essere larga 0.3 metri. (se siete veramente ma veramente ma veramente pigri potete usare questo).

Il risultato finale dovrebbe essere qualcosa del genere.

L’inserimento dell’immagine può essere fatto in modo “smart” anche usando alcuni nodi nel package archi-lab. Il workflow è descritto qui nell’applicazione prevista da Konrad Sobon, il suo sviluppatore. Le immagini sono prese da quel post (il mio Revit è ancora in crash per colpa del Van Gogh che vedrete tra poco).

Il nodo Image Import Options offre la possibilità di scegliere il posizionamento da un menu a tendina, dentro al nodo Box Placement Types e richiede poi di specificare il punto centrale e la risoluzione dell’immagine. Il nodo è utilizzabile come input in un nodo speciale Image.Import.

Sempre di Konrad Sobon, segnalo questo recente articolo in cui fa la stessa cosa con Google Maps.

2.4. Tutto qui?

Come siete pignoli. No, non è tutto qui, ma per procedere ulteriormente bisogna addentrarsi nel magico mondo di tutto ciò che si può fare con le immagini e Dynamo all’interno di Revit. Che non è tantissimo, ma è meglio di niente.

All’interno del primer trovate una serie di esercizi a riguardo nella sezione che si occupa della gestione dei colori.

La prima parte del workflow è poco interessante per noi, perché si limita a creare la superficie.

La parte che ci interessa è la successiva: il nodo Display.BySurfaceColors consente di mappare i colori nei pixel dell’immagine e di spalmarli su una superficie.

In questo caso, l’esempio usa un quadro di Van Gogh. Nel nostro caso, l’immagine potrebbe essere la nostra mappa.

Questo ci consentirebbe ad esempio di visualizzare la mappa in tre dimensioni all’interno dello spazio di Dynamo, anche in condizioni in cui integrare l’immagine sarebbe oneroso in termini di modello (ad esempio creando una decal). Non che lo script sia leggero (perché pensate che ve lo stia facendo vedere usando le immagini del primer?).