Vurdering av særskilt distribusjon (50 øre per liter)

Grande parte dos catálogos até agora apresentados são referentes aos fornecedores "primários"deste tipo de dados. De forma a enriquecer estesurvey, apresenta-se agora um

fornecedorthird party - a Google através do GEE [116].

O GEE é uma plataforma de processamento, suportada por tecnologiascloud, especia-

lizada em dados geoespaciais, tirando partido da enorme capacidade computacional da Google. Esta foi desenhada não apenas tendo em conta os interesses dos especialistas de deteção remota, mas também os das audiências com insuficiência técnica para recorrer a recursos de computação de larga escala. Para este efeito, esconde-se os detalhes: de ingestão dos dados de processar uma enorme variedade de formatos; de gerir uma base de dados; de alocar máquinas; entre outras tarefas necessárias à computação. A análise desta plataforma será suportada por duas vertentes principais: catálogo e arquitetura. Visto que o catálogo inclui a cobertura, âmbito e metamodelo do mesmo. Por outro lado, na arquitetura são exploradas as caraterísticas funcionais.

Catálogo Neste está presente todo o arquivo do Landsat, Sentinel-1 e Sentinel-2. In- cluindo também previsões climáticas, dados de cobertura do terreno e outros conjuntos de dados ambientais, geofísicos e também socioeconómicos, como apresentado na Fig.I.8. Apesar de a oferta ser muito ampla, é possível fazerupload de um produto, por forma a

processá-lo. De referir que isto não se trata de uma automatização da ingestão, mas sim de um mecanismo deupload ad hoc para uma área privada.

Relativamente ao metamodelo, este é bastante genérico, tendo informação sobre a localização, data de aquisição e condições sobre as quais as imagens foram recolhidas

2 . 4 . C ATÁ L O G O S E P L ATA F O R M A S

e processadas. Ilustrando a expressividade deste metamodelo, seria possível pesquisar imagens diurnas do Landsat 8 que intersetem qualquer parte do território português no dia do ano de 80 a 104, dos anos 2010 até 2012, com uma cobertura de nuvens inferior a 5%.

Outro ponto interessante deste catálogo é o facto dos utilizadores terem a possibili- dade de partilhar os produtos processados e os seusscripts, e até recorrer a ferramentas

de criação de aplicaçõesweb de exploração dos dados computados. De referir que o meca-

nismo de inserção de novos tipos de produtos não envolve a definição sistemática de um metamodelo, não existindo também a possibilidade de colaboração no enriquecimento do mesmo. Finalmente, após o desenvolvimento de um certo algoritmo, é possível produzir sistematicamente o produto resultante.

Arquitetura Em 2017, os responsáveis por idealizar esta plataforma publicaram um artigo no qual apresentam uma arquitetura simplificada da mesma [117]. Na Fig.2.11

é representada essa arquitetura, sendo que esta é possível dividir-se em três camadas: apresentação, computação e armazenamento.

Figura 2.11: Arquitetura simplificada do GEE. [117]

Começando pela primeira camada referida, o editor de código do GEE e as aplica- çõesweb de entidades externas, que recorrem às bibliotecas tanto de Javascript como de

Python, de forma a interrogar o sistema através da API REST. Focando no editor de código, este permite desenhar cadeias complexas de processamento geoespacial. Na Fig.2.12es- tão representadas um conjunto de caraterísticas que permitem tirar vantagem da API do GEE. Para além de editar o código, é também possível gerir osscripts, procurar conjuntos

até partilhar osscripts. Relativamente às API Python e Javascript, estas incorporam um

paradigma de programação influenciado pela necessidade de distribuição tanto do arma- zenamento como da computação. Uma vez que ao existir um paradigma poderão surgir alguns problemas de flexibilidade na implementação de novos algoritmos, isto é, as opera- ções são pré-definidas pela API. Um exemplo concreto deste facto surgiu no contexto do desenvolvimento respetivo ao caso de estudo da Secção5.3.4. Na implementação de um dos algoritmos, era necessário contar o número de píxeis de uma imagem Landsat (reso- lução de 30x30m) dentro de um píxel de uma imagem MODIS (resolução de 250x250m). Sem recorrer a API do GEE bastaria fazer uma interseção dos píxeis. Já no GEE, segundo o autor, era bastante mais complicado,sendo necessário seguir os seguintes passos: (i) criar um polígono para cada píxel da imagem MODIS; (ii) sobrepor esse polígono com a imagem Landsat; (iii) e, por fim, para cada polígono, executar a operação reduce, através da qual era possível obter a contagem de píxeis Landsat que existem dentro do mesmo.

Figura 2.12: Diagrama de componentes do editor de código do GEE. [118]

Após a submissão dequeries interativas, os servidores front end subdividem estas e

enviam as unidades de trabalho resultantes para osmasters, os quais gerem um conjunto

de servidores de computação. As computações embatch são executadas de forma seme-

lhante, mas recorrem a umaframework de processamento paralelo para gerir a distribuição

- FlumeJava [119]. Geralmente, o ciclo de desenvolvimento começa pela exploração dos dados e implementação do algoritmo de uma forma interativa. Após esta fase, aplica-se o mesmo numa escala maior através do mecanismo de processamento embatch, o qual irá

materializar o produto resultante no formato correspondente. Quando se usa a expressão "aplicar numa escala maior"neste contexto, pretende-se assinalar que, no contexto das

2 . 5 . C O N C LU S ÃO

caso se esteja a desenvolver no editor de código do GEE, pode ser suficiente computar ape- nas a área visualizada correspondente ao mapa presente no editor de código (Fig.2.12). Isto permite que o utilizador não tenha preocupações em projetar o resultado para áreas específicas, já que esse passo é feito de forma automática.

Passando à camada de armazenamento, esta tem uma componente de metadados e ou- tra de dados. Os primeiros estão armazenados na Asset Database, e contêm os metadados das imagens, permitindo pesquisas eficientes. Relativamente aos dados, é nos Tilestore Servers que está presente a informação em formatoraster. Por outro lado, a informação

vetorial, está presente nas Fusion Tables [120], uma base de dados que suporta tabelas de dados geométricos (pontos, linhas, polígonos).