Inicialmente foi criado um projeto que engloba várias pastas, (“assets”; “data”, que engloba todos os ficheiros importados; “imagens”; “mapas”; “modelos exportados”; “rules”, que engloba todos os ficheiros de regras; “cena”, que nos mostra o projeto em três dimensões com grande rigor; “scripts”, desenvolvidos fora do software e importados para o mesmo).
i. Criação de um Terreno
A partir daqui foi necessário a criação de um terreno, com a elevação visível no projeto. Desta forma, com o modelo digital de terreno adquirido anteriormente, com os
cortes exatos do centro histórico e com uma imagem de satélite retirada do basemap utilizado anteriormente também recortado com os limites referidos, colocamos as duas na opção de criação de um terreno para o projeto, em que o MDT modela a altitude e a imagem retrata a textura com que ficará representado o terreno.
47
Figura 13 - Ficheiros de entrada para a criação do terreno. Fonte: Projeto do autor (CityEngine 2017.1).
Os ficheiros referentes ao edificado e às vias foram inseridos através da opção file
gdb import, que possibilita importar todos os ficheiros de uma só vez, sendo todos
guardados na pasta data anteriormente criada.
ii. Realização do script utilizado para a modelação dos edifícios
Para a modelação dos edifícios foi necessário um script realizado em linguagem
CGA. O software de modelação utilizado já contém vários scripts que por sua vez,
retratam diferentes tipos de cidade, com alguns exemplos específicos, como Paria, Turim,
Philadelphia, Redlands, Veneza, Pompeii, entre outras. No entanto, como estamos
perante um estudo que pretende ter o maior rigor possível, não só nas suas análises, mas também em todo o seu processamento básico, foi decidido a realização de um próprio
script deveria retratar o caso de Vila Nova de Gaia. Desta forma, com a aprendizagem
anteriormente adquirida e com apoio de contactos fornecidos pela Orientadora e pela instituição de estágio, sobretudo de especialistas em informática e programação, foi possível desenvolver um script com várias versatilidades, que pode representar
48
normalmente qualquer tipo de cidade, apenas com algumas mudanças em comandos também criados neste mesmo script. Assim, por defeito, contém definições relativas à cidade em estudo que a qualquer momento podem ser alterados para representar uma área distinta.
Figura 14 - Script do edificado.
Fonte: Elaborado pelo autor (CityEngine 2017.1).
Alguns dos pontos do script aqui explicados, podem ser confirmados com a análise dos principais scripts incluídos em anexos do presente relatório.
Inicialmente, foi criado um ficheiro CGA na categoria rule, a 6 de outubro de 2017, com a versão 2017.0, ficheiro criado com o maior rigor e uniformidade possível tendo em conta a curta experiência em programação.
Foram criados diversos comentários para desta forma ser mais percetível o procedimento a qualquer utilizador que futuramente possa utilizar o mesmo ficheiro. Foi desenvolvido um título e explicação das funções principais do programa desenvolvido e após isto, foram criados 4 grupos de apresentação ao utilizador, onde foram disponibilizadas todas as definições existentes e alteráveis dependendo da sua categoria. Em todas estas categorias existem várias opções para podermos alterar a qualquer momento, contendo também uma opção em todas as categorias, que faz a ligação
49
automática com algum campo da tabela de atributos do ficheiro em questão, o que facilita em casos em que existe grande quantidade de dados.
A primeira categoria denominada como “Main Features” representa funções como a categoria de construção a que pertence o edifício que estamos a selecionar (caso exista uma categorização da forma de construção do edifício como no caso), altura do edifício, altura de cada piso, área, largura das janelas, largura das portas, display que deve ser representado e número de edifício caso estejamos perante um edifício em que é fornecido as fachadas reais e exatas do mesmo.
A segunda categoria, “Roofs” contém definições relativas à construção dos telhados que permite selecionar o tipo de telhado (flat, gable ou hip), que por sua vez, identificamos como telhados flat, todos os revestimentos que não contêm altura e são completamente planos. Este tipo de telhados é constantemente encontrado em edifícios de construção recente. Gable, são todos os telhados que têm duas vertentes, por norma situados dos lados mais compridos do edifício, encontrados estes maioritariamente em anexos. O terceiro tipo, hip, é representado com as quatro vertentes de telhado, contendo este a maior parte dos edifícios, desde a moradias térreas, edifícios de construção antiga e as caves no caso de Vila Nova de Gaia.
O quarto grupo de definições criadas engloba três opções como: 1º - A unidade de medida em que queremos trabalhar, (metro);
2º - Ano de construção do edifício que pode ser depois utilizado para reportar informação quando exportados os resultados obtidos;
3º- A transparência que colocamos em todo o projeto ou apenas em cada objeto selecionado, que foi concebida de modo a que qualquer pessoa consiga manipular apenas com a ótica do utilizador para futuro acesso ao programa desenvolvido.
Para além das definições referidas anteriormente, foram colocadas outras também importantes para facilitar a adaptação do código para a inserção de diferentes objetos de áreas distintas. Podemos consultar na figura 16, as opções ao qual o utilizador consegue
50
manipular a modelação, sem qualquer tipo de obrigatoriedade de preenchimento devido ao facto de existirem valores colocados por defeito.
Figura 15 - Funções do script do edificado. Fonte: Elaborado pelo autor (CityEngine 2017.1)
A partir daqui, foi colocada a regra em execução, ou seja, neste ponto o sistema lê todas as definições requisitadas pelo utilizador, verificando se existe possibilidade para a execução. Caso seja possível, começa a realizar ponto a ponto todo o script para trabalhar cada linha de código com a maior precisão.
Após colocar o programa em execução através da startrule, com a primeira e mais importante regra “Edificado” para a modelação inicial que agrega o alinhamento automático do escopo com o eixo y, o que faz com que todos os edifícios sofram um
51
alinhamento no terreno. Foi agregada também a função extrude, que por sua vez faz crescer qualquer edifício segundo a altura do mesmo, através da função comp foi possível a divisão entre o telhado e as paredes dos edifícios para desta forma nomear cada uma das divisões para após isto ser possível a caracterização ao pormenor sem interferir uma com a outra. Por último, uma função essencial de todo o script, que se descreve como
report mostra-nos a área de qualquer objeto sem ser necessário aceder a qualquer ficheiro
como a tabela de atributos, ou qualquer outro tipo de informação formatada pelo utilizador.
As funções a partir daqui são especificamente detalhadas para toda a construção dos objetos, nomeadamente os telhados, onde é explicado resumidamente os pontos em que o programa assenta neste parâmetro. Um ângulo de 0,5 graus para telhados gable, 1,2 graus para telhados hip e cerca de 1 metro de altura de um pequeno muro que liga as paredes do edifício ao cimo do mesmo em telhados flat, notando-se que estes contêm em todos os casos os mesmos pormenores de construção. Todos estes valores colocados, respeitam na sua maioria a realidade da área em estudo. Os telhados flat e gable contêm fachadas para o exterior que para conseguir uma maior realidade é colocada uma textura, com a definição por defeito da cor branca na maioria dos casos.
Figura 16 - Exemplos da modelação dos tipos de telhados. Fonte: Projeto do autor (CityEngine 2017.1)
Na primeira imagem da figura 16, identificamos um telhado de forma gable, que neste caso, tem a sua fachada já incluída no telhado com a construção de janelas, no
52
entanto pode ser também atribuída qualquer cor ou qualquer outra imagem. No caso de atribuir uma imagem, é utilizada uma função presente na programação desta linguagem chamada de setupProjection, que por sua vez insere um tamanho de projeção que desejamos colocar na textura tendo em conta o tamanho da superfície. Neste caso, foi utilizada esta função para a projeção de imagens nestas fachadas do telhado gable e flat, para existir a possibilidade de tirarmos uma fotografia do local e colocar no sítio exato.
Na segunda imagem da figura 16, podemos avistar um edifício com superfície flat, que tem o aumento anteriormente referido de 1 metro destacado a cinzento escuro. Na terceira imagem da mesma figura é retratado um telhado na forma de construção hip, que se destaca pelas suas 4 vertentes.
A função de projeção de fotografias foi também utilizada para o topo dos telhados, onde por defeito foram colocadas 2 fotografias de telhas, que se identificam ambas por “telha em barro” para os telhados gable e hip, com tamanho de projeção de 17.4 metros quadrados. Para o telhado flat foi colocada a cor cinzento escuro por defeito, com a possibilidade de o utilizador colocar imagens com a mesma projeção dos telhados anteriores.
Com a opção “textures” no “display Type”, o programa irá solicitar texturas para colocarmos para o preenchimento das fachadas, em que não são diferenciados o tipo de categoria dos edifício, mas apenas é realizado um ciclo aleatório e as imagens projetadas nos edifícios aleatoriamente, caso contrário, se escolhermos a opção “construction”, o
Figura 17 - Construção das portas e das janelas dos edifícios Fonte: Projeto do autor (CityEngine 2017.1)
53
programa segue para uma diferenciação de categorias inseridas e de características especiais na sua construção. Desta forma, faz uma identificação da categoria a que respeita cada objeto que colocamos de 1 a 10. Na maioria das categorias como na primeira, é realizado o corte do edifício em pequenas partes, para ser possível a inserção de janelas, portas e bordas, atualmente com medidas universais de 1,40 metros de largura e 0,75 metros de altura para as janelas. As portas têm 1 metro de largura e 2,40 metros de altura, contendo todas estas janelas e portas contém uma borda de 0,10 metros. Todas as categorias, dentro da opção “construction”, têm também a opção de ser colocada uma textura para preencher as fachadas ou então uma cor.
Esta construção é semelhante em praticamente todas as categorias neste momento, sendo este o script que terá um grande número de intervenções de manutenção para o futuro como a atualização destes pontos, que em cada categoria fará sentido ter o seu tipo de construção com o tamanho específico de portas, janelas e bordas. No entanto, neste momento, a categoria 2 (edifícios recentes), diferencia apenas o telhado à semelhança da categoria 5 (outros edifícios de construção recente) e 3 (caves). A categoria 4 (armazéns) contém apenas uma porta em cada fachada das dimensões referidas anteriormente. A categoria 6 (anexos), é construída com apenas uma janela e uma porta das mesmas dimensões. A categoria 7 (silos) apenas contém a opção para colocarmos uma textura ou uma cor, devido a não fazer sentido a repartição em blocos para construção neste caso. A categoria 8 (escadas), 9 (estacionamentos) e 10 (pátios) assemelham-se atualmente à categoria 8, no entanto, estas requerem atualização futuramente.
iii. Compreensão e utilização do script utilizado para a modelação das vias
Para a modelação das vias, seria necessário um script com funcionalidades bastantes simples, para modelar as vias de comunicação em questão, visto estarmos perante uma área maioritariamente composta por ruas em paralelo. Isto existe em praticamente todos os ficheiros de regras do software. Desta forma, após bastante trabalho de investigação em todos os ficheiros de regras existentes, foi encontrado e testado o
54
“Complete_Street.cga”, criado a 26 de janeiro de 2015, que por sua vez, coloca a realidade um pouco mais avançada e oferece a possibilidade de inserir objetos que representam automóveis, população e mobiliário urbano.
Assim, não foi necessária a construção de um ficheiro de regras como no caso da modelação dos edifícios. Compreendido este script da autoria da Esri, verificou-se ser completamente versátil nesta situação, pois todas contêm bastante generalização na sua construção e não características próprias e únicas.
Este ficheiro de regras utiliza outros da mesma autoria para o seu pleno funcionamento, pois estamos perante um conjunto de regras bastante complexo, que para a inserção de objetos representativos de população, automóveis e mobiliário urbano, necessita de importar e construir objetos em 3 dimensões assimilando essas regras noutros
scripts e noutras pastas como, “3DModels_from_LowPolygon3D.com”,
“LowPolygon3D.com_Vehicles”, “LowPolygon3D.com_Cyclists”, “LowPolygon3D.com_People”.
Figura 18 - Resultados da modelação do script das vias. Fonte: Projeto do autor (CityEngine 2017.1)
55
No sentido de colocar todo o projeto funcional e com grande versatilidade, todas estas pastas e scripts necessárias ao seu funcionamento, foram colocadas na pasta assets criada no projeto a realizar.
Os tipos arbóreos presentes neste script não foram utilizados, como foi relatado anteriormente, desta forma, foi realizado todo este processo separadamente.
iv. Erros iniciais da informação e correção dos mesmos
Quando gerados os dados no programa, foram descobertos vários erros que teriam de ser corrigidos para conseguir a melhor modelação possível. Assim, inicialmente existiam paragens de processamento no momento da leitura do script da modelação do edificado. Desta forma e com a impossibilidade de não ser resolvidos, contactamos a Esri, depois de vários testes a todos os pontos mais prováveis de erro. A instituição, em reunião com os seus técnicos, identificou o erro nos próprios ficheiros fornecidos pela GAIURB, tanto do edificado como das vias. Especificamente, existiam cerca de 4 edifícios e 1 via com o erro. Erro esse que foi considerado como ficheiros corrompidos ou danificados, que maioritariamente acontece quando existem bastantes alterações dos ficheiros.
Para identificar os 5 ficheiros corrompidos foi necessário a verificação de ficheiro a ficheiro. A partir daqui, em reunião com os Orientadores foram feitas várias tentativas para resolver o problema sem apagar os objetos em questão, no entanto, a única opção existente no final de bastantes dias de trabalho, foi a remoção dos mesmos. Tal procedimento não teve grande interferência com o projeto pois os elementos em questão situavam-se no interior da área e tinham uma área bastante reduzida.
A seguir, foi verificado um outro problema referente à altura de alguns edifícios. Vários edifícios apresentavam valores relativos à altura, negativos e nulos. Esta foi uma situação crítica, devido ao facto da altura (z) ser um dos fatores mais importantes para a modelação dos edifícios. Desta forma, cada edifício foi corrigido com a maior exatidão possível, através da ferramenta editor e com suporte do software Google Earth, em que foi possível a medição dos edifícios com a ferramenta da régua. Esta alteração dos valores
56
iniciais foi apoiada também por várias saídas de campo, em alguns casos de difícil análise em suporte informático.
Ainda dentro da correção do erro das alturas, foi criado um campo na tabela de atributos (fiels witch correction) que indica quais os campos que tiveram e não a correção das alturas. Para além do campo das alturas ser corrigido, foram também modificadas as diferentes áreas dos edifícios com suporte às mesmas metodologias anteriormente utilizadas. Da mesma forma que foi verificado o número de ficheiros, foram verificados os ficheiros com as alturas corrigidas após serem anotadas no novo campo criado, em que todas as alturas corrigidas eram preenchidas com “Yes” e os campos que não tiveram alteração com “No”. Assim, foi tido em conta e como referência os dados que não foram alterados, distinguindo-os facilmente. A sua correção foi feita “manualmente” em que foi verificado cada edifício, atribuindo um critério de correção uniforme aos que estava impossibilitada a medição, para se conseguir aproximar o mais possível da realidade. Foram contabilizados 1029 ficheiros com alturas negativas. No caso em que não era possível a medição nas circunstâncias em que me encontrava, eram atribuídas as alturas do edifício que se encontra junto a este.
Seguidamente, em ficheiros com existência desnecessária, como o caso de chaminés que se situavam em áreas que atualmente não existem, ou no caso de outros ficheiros que representam ruínas, foram removidos para poder retratar o melhor possível a realidade.
À categoria dos silos, que foi necessário o seu cadastro, foram atribuídas as alturas de 6 metros nos de pequeno porte e 12 metros nos de grande porte (Carneiro, 1948). Foram criados então 4 silos, em que 3 são de 12 metros e 1 de 6 metros.
Todos os pátios foram colocados com altura de 0 metros, para facilitar a modelação, pois estes encontram-se na sua totalidade à altura do solo.
Após serem constatados os problemas referidos foi percetível que existia, na maior parte dos casos uma representação do polígono de cada edifício apenas pelo seu
57
perímetro, o que dificulta sua modelação, pois o software CityEngine assume um telhado para todo o edifício.
Figura 19 - Exemplos de edifícios com erros e delimitação e correções. Fonte: Projeto do autor (CityEngine 2017.1)
Na figura 19 são visíveis os resultados da modelação com o erro da delimitação dos edifícios, ou seja, neste caso verificam-se telhados com dimensões completamente fora
Edifícios com erros de delimitação
58
da realidade, porque o software modela os telhados segundo o perímetro, ou seja, quanto maior for a área do edifício, maior será a altura do telhado. As imagens da figura 20, mostram os edifícios com erros de delimitação e os resultados após correção dos mesmos numa vista aérea.
Figura 20 - Edifícios com erros de delimitação de vista aérea e suas correções. Fonte: Projeto do autor (CityEngine 2017.1).
Antes dos dados serem tratados para a resolução deste problema, como vemos na primeira imagem da figura 20, apenas são contornados os edifícios pelo seu perímetro e não pelos cortes exatos do telhado.
A solução que foi escolhida para este tipo de incompatibilidade, assemelha-se com as soluções anteriores, ou seja, a correção manual, por uma questão de uniformização dos processos de correção. Assim, com o apoio da ferramenta editor anteriormente utilizada, procedeu-se ao recorte do ficheiro dos edifícios com o apoio dos softwares utilizados em cada processo de correção e decisão. Para além disto, neste caso especificamente ao
basemap do ArcGis, pois desta forma foi possível os cortes com todos os pormenores.
59
Todos os novos ficheiros adquiriram as alturas que o ficheiro antigo inicial continha, todas as áreas são recalculadas com a função Calculate Geometry, disponível para cada coluna da tabela de atributos. Este corte foi fundamental por várias razões, nomeadamente pela diferença dos valores dos resultados adquiridos, quando a principal análise deste projeto se prende à modelação dos telhados dos edifícios.
Nesta altura, foi percetível que a modelação ainda não tinha o maior rigor possível devido aos limites em que se encontravam recortadas as vias de comunicação pois, na sua maioria eram limitadas no meio de rotundas, entroncamentos e áreas de difícil finalização da modelação. Desta forma, foi então decidido após reunião com o Orientador da Instituição de Estágio, que a melhor solução seria aumentar a área numa extensão de cerca de 30 metros, após analisar todas a vias nessa distância. Assim, foi realizado um buffer de 30 metros, com a ferramenta buffer analysis ao MDT anteriormente realizado. A partir daqui, tínhamos então mais 30 metros para além da margem do rio que não era desejado nesta área, assim com a ferramenta extract by mask, spatial analysis, este ficheiro foi recortado pela margem do rio.
Como a categorização das vias de comunicação já tinha sido realizada anteriormente, este novo ficheiro não continha o campo “categoria”, desta forma, foi realizada uma junção de tabelas de atributos, do ficheiro que já continha a categorização com o novo ficheiro, através da ferramenta join, com a referência do campo “tipo de estrada”. A seguir foi necessária uma categorização de todas as vias do novo ficheiro. Para facilitar este tipo de operação foi transformado este ficheiro em KMZ para ser possível a categorização no software Google Earth, através da ferramenta acima utilizada no processo semelhante.
v. Modelação do Rio Douro
Um dos processos mais complexos na modelação da área de estudo, foi o