Share via

Armazenamento, análise e visualização geoespacial de ponta a ponta

  • Artigo

Os dados geoespaciais vêm em várias formas e requerem uma ampla gama de capacidades para processar, analisar e visualizar os dados. Embora o Sistema de Informação Geográfica (SIG) seja comum, também não é, em grande parte, nativo da nuvem. A maioria dos SIG é executada no ambiente de trabalho, o que limita a sua escala e desempenho. Embora tenha havido avanços na movimentação dos dados para o back-end, esses sistemas permanecem vinculados a IaaS, o que os torna difíceis de escalar.

Este artigo fornecerá uma abordagem de alto nível para usar recursos nativos da nuvem, juntamente com algumas opções de software de código aberto e opções comerciais. Serão consideradas três personas. As personas são arquitetos que procuram um fluxo de alto nível sem entrar nas especificidades de uma implementação. As personas incluem o seguinte:

  • Arquiteto geoespacial geral. Este arquiteto está à procura de um meio para implementar geoespacial, mas pode não ter experiência em SIG ou Deteção Remota.
  • Arquiteto geoespacial OSS. Este arquiteto dedica-se a uma solução de software de código aberto (OSS), mas tira partido da nuvem para computação e armazenamento.
  • Arquiteto geoespacial COTS. Este arquiteto dedica-se ao COTS, mas também tira partido da computação e armazenamento na nuvem.

Potenciais casos de utilização

As soluções fornecidas nestas arquiteturas aplicam-se a muitos casos de uso:

  • Processamento, armazenamento e fornecimento de acesso a grandes quantidades de dados raster, como camadas ou dados climáticos.
  • Combinar dados de localização de entidades de sistemas ERP com dados de referência SIG ou incluir dados vetoriais, matrizes, nuvens de pontos, etc.
  • Armazenando telemetria da Internet das Coisas (IoT) a partir de dispositivos em movimento e analisando em tempo real ou em lote
  • Execução de consultas geoespaciais analíticas.
  • Incorporação de dados geoespaciais curados e contextualizados em aplicações Web.
  • Processamento de dados de drones, fotografia aérea, imagens de satélite, LiDAR, resultados de modelos em grade, etc.

Arquitetura geoespacial geral

O Azure tem muitas capacidades geoespaciais nativas. Neste diagrama e nos que se seguem, você encontrará estágios de alto nível nos quais os dados geoespaciais são submetidos. Primeiro, você tem a fonte de dados, uma etapa de ingestão, um local onde os dados são armazenados, transformados, servidos, publicados e, finalmente, consumidos. Observe o ícone de globo ao lado dos serviços com capacidades geoespaciais nativas. Além disso, esses diagramas não devem ser considerados processos lineares. Pode-se começar na coluna Transformações, Publicar e Consumir e, em seguida, criar alguns conjuntos de dados derivados, o que requer voltar a uma coluna anterior.

Geospatial On Azure

Este fluxo de arquitetura pressupõe que os dados podem ser provenientes de bancos de dados, arquivos ou fontes de streaming e não armazenados em um formato SIG nativo. Depois que os dados são ingeridos com o Azure Data Factory, ou por meio do Azure IoT, Hubs de Eventos e Stream Analytics, eles podem ser armazenados permanentemente em armazenamento morno com o Azure SQL, a Instância Gerenciada do SQL do Azure, o Banco de Dados do Azure para PostgreSQL ou o Armazenamento do Azure Data Lake. A partir daí, os dados podem ser transformados e processados em lote com o Azure Batch ou o Synapse Spark Pool, dos quais ambos podem ser automatizados por meio do uso de um pipeline do Azure Data Factory ou Synapse. Para dados em tempo real, eles podem ser transformados ou processados com o Stream Analytics, o Azure Maps ou contextualizados com os Gêmeos Digitais do Azure. Depois que os dados forem transformados, eles poderão ser novamente servidos para usos adicionais no Banco de Dados SQL do Azure ou no Banco de Dados do Azure para PostgreSQL, no Pool SQL do Synapse (para dados não geoespaciais abstratos), no Azure Cosmos DB ou no Azure Data Explorer. Uma vez prontos, os dados podem ser consultados diretamente através da API da base de dados, mas frequentemente uma camada de publicação é usada. A API de Dados do Azure Maps seria suficiente para pequenos conjuntos de dados, caso contrário, um serviço não nativo pode ser introduzido com base em OSS ou COTS, para acessar os dados por meio de serviços Web ou aplicativos de área de trabalho. Finalmente, o SDK da Web do Azure Maps hospedado no Serviço de Aplicativo do Azure permitiria a geovisualização. Outra opção é usar o Azure Maps no Power BI. Por fim, o HoloLens e as Âncoras Espaciais do Azure podem ser usados para exibir os dados e colocá-los no mundo real para experiências de realidade virtual (VR) e realidade aumentada (AR).

Deve-se notar também que muitas dessas opções são opcionais e podem ser complementadas com OSS para reduzir custos, mantendo também a escalabilidade, ou ferramentas de terceiros para utilizar seus recursos específicos. A próxima sessão aborda esta necessidade.

3rd Party e arquitetura geoespacial de software de código aberto

Esse padrão adota a abordagem de usar recursos geoespaciais nativos do Azure e, ao mesmo tempo, aproveitar algumas ferramentas de terceiros e ferramentas de software de código aberto.

A diferença mais significativa entre esta abordagem e o fluxograma anterior é a utilização do FME da Safe Software Inc., que pode ser adquirido no Azure Marketplace. O FME permite que arquitetos geoespaciais integrem vários tipos de dados geoespaciais, incluindo CAD (para Azure Maps Creator), GIS, BIM, 3D, nuvens de pontos, LIDAR, etc. Existem 450+ opções de integração, e pode acelerar a criação de muitas transformações de dados através de sua funcionalidade. A implementação, no entanto, é baseada no uso de uma máquina virtual e, portanto, tem limites em seus recursos de dimensionamento. A automação de transformações FME pode ser alcançada usando chamadas de API FME com o uso do Azure Data Factory e/ou com o Azure Functions. Depois que os dados são carregados no SQL do Azure, por exemplo, eles podem ser servidos no GeoServer e publicados como um Web Feature Service (vetor) ou Web Mapping Tile Service (raster) e visualizados no SDK da Web do Azure Maps ou analisados com o QGIS para área de trabalho junto com os outros mapas base do Azure Maps.

Diagram of Azure and 3rd Party tools and open-source software.

Arquitetura geoespacial COTS: Esri com fontes estáticas e de streaming

A próxima abordagem que analisaremos usa SIG comercial como base para a solução. A tecnologia da Esri, disponível no Azure Marketplace, será a base para essa arquitetura, embora outros softwares comerciais possam se encaixar nos mesmos padrões. Como antes, as fontes, ingestão, armazenamento (bruto), Load/Serve permanecem em grande parte as mesmas. Os dados também podem ser transformados com ArcGIS Pro em um computador autônomo (VM) ou como parte de uma solução maior com a Área de Trabalho Virtual do Azure. Os dados podem ser publicados via ArcGIS Enterprise ou com o ArcGIS Enterprise no Kubernetes (Serviço Kubernetes do Azure). As imagens podem ser processadas em IaaS com ArcGIS Image como parte da implantação do ArcGIS Enterprise. Os dados podem ser consumidos em aplicativos da web hospedados no Serviço de Aplicativo do Azure com o ArcGIS JavaScript SDK, um usuário final do ArcGIS Pro, ArcGIS Runtime mobile SDK ou com ArcGIS for Power BI. Da mesma forma, os usuários podem consumir os dados com ArcGIS Online.

Diagram of Esri with static and streaming sources.

Arquitetura de imagens geoespaciais COTS: ArcGIS Image da Esri e Azure Orbital

A próxima arquitetura envolve o Azure Orbital e ArcGIS Image da Esri. Com esse fluxo de ponta a ponta, o Azure Orbital permite agendar contatos com satélites e fazer downlink dos dados em uma VM ou transmitir para os Hubs de Eventos do Azure. Além dos dados de satélite transmitidos diretamente, os dados de drones ou outras imagens podem ser trazidos para a plataforma e processados. Os dados brutos podem ser armazenados nos Arquivos NetApp do Azure, em uma conta de Armazenamento do Azure (blob) ou em um banco de dados como o Banco de Dados do Azure para PostgreSQL. Dependendo da plataforma de satélite e sensor, os dados são transformados do conjunto de dados de Nível 0 para Nível 2. Consulte os níveis de processamento de dados da NASA. Para que nível é necessário, depende do satélite e sensor. Em seguida, o ArcGIS Pro pode transformar os dados em um Mosaic Dataset. O Mosaic Dataset é então transformado em um serviço de imagem com ArcGIS Enterprise (em VMs ou Kubernetes). O ArcGIS Image Server pode servir os dados diretamente como um serviço de imagem ou um usuário pode consumir o serviço de imagem via ArcGIS Image for ArcGIS Online.

Diagram of Esri's ArcGIS Image and Azure Orbital.

COTS/Arquitetura de imagens geoespaciais de software de código aberto: Conjunto de dados pronto para análise do Azure Space to Analysis

Quando os conjuntos de dados prontos para análise são disponibilizados por meio de APIs que permitem recursos de pesquisa e consulta, como no Planetary Computer da Microsoft, não há necessidade de primeiro baixar os dados de um satélite. No entanto, se forem necessários tempos de entrega baixos para imagens, a aquisição dos dados diretamente do Espaço Azure é ideal porque um operador de satélite ou uma organização orientada por missão pode agendar um contacto com um satélite através do Azure Orbital. O processo para passar do nível 0 para o conjunto de dados pronto para análise de nível 2 varia de acordo com o satélite e os produtos de imagem. Muitas vezes, são necessárias várias ferramentas e etapas intermediárias. O Lote do Azure ou outro recurso de computação pode processar os dados em um cluster e armazenar os dados resultantes. Os dados podem passar por várias etapas antes de estarem prontos para serem utilizados no ArcGIS ou QGIS ou alguma outra ferramenta de geovisualização. Por exemplo, quando os dados estão em um formato Cloud Optimized GeoTIFF (COG), eles são servidos por meio de uma Conta de Armazenamento ou Azure Data Lake e tornados acessíveis e consultáveis por meio da API STAC, que pode ser implantada no Azure como um serviço, com AKS, entre outros. Como alternativa, os dados são publicados como um Web Mapping Tile Service com GeoServer. Os consumidores podem então acessar os dados no ArcGIS Pro ou QGIS ou através de um aplicativo da web com o Azure Maps ou SDKs móveis e da web da Esri.

Diagram of Azure Space to Analysis Ready Dataset.

Componentes

Embora não sejam mostrados nos diagramas acima, o Azure Monitor, o Log Analytics e o Key Vault também fariam parte de uma solução mais ampla.

  • O Azure Monitor coleta dados sobre ambientes e recursos do Azure. Essas informações de diagnóstico são úteis para manter a disponibilidade e o desempenho. Duas plataformas de dados compõem o Monitor:
  • O Azure Log Analytics é uma ferramenta do portal do Azure que executa consultas nos dados de log do Monitor. O Log Analytics também fornece recursos para gráficos e análise estatística dos resultados da consulta.
  • O Key Vault armazena e controla o acesso a segredos como tokens, senhas e chaves de API. O Cofre de Chaves também cria e controla chaves de criptografia e gerencia certificados de segurança.

Alternativas

Várias bibliotecas do Spark estão disponíveis para trabalhar com dados geoespaciais no Azure Databricks e Synapse Spark Pools. Veja estas bibliotecas:

Mas também existem outras soluções para processar e dimensionar cargas de trabalho geoespaciais com o Azure Databricks.

  • Outras bibliotecas Python a considerar incluem PySAL, Rasterio, WhiteboxTools, Turf.js, Pointpats, Raster Vision, EarthPy, Planetary Computer, PDAL, etc.

  • Os mosaicos vetoriais fornecem uma forma eficiente de apresentar dados SIG em mapas. Uma solução poderia usar PostGIS para consultar dinamicamente blocos vetoriais. Essa abordagem funciona bem para consultas simples e conjuntos de resultados que contêm bem menos de 1 milhão de registros. Mas, nos seguintes casos, uma abordagem diferente pode ser melhor:

    • Suas consultas são computacionalmente caras.
    • Seus dados não mudam com frequência.
    • Você está exibindo grandes conjuntos de dados.

Nessas situações, considere o uso de Tippecanoe para gerar telhas vetoriais. Você pode executar o Tippecanoe como parte do seu fluxo de processamento de dados, como um contêiner ou com o Azure Functions. Você pode disponibilizar os blocos resultantes por meio de APIs.

  • Como os Hubs de Eventos, o Hub IoT do Azure pode ingerir grandes quantidades de dados. Mas o Hub IoT também oferece recursos de comunicação bidirecional com dispositivos. Se você receber dados diretamente de dispositivos, mas também enviar comandos e políticas de volta para dispositivos, considere o Hub IoT em vez de Hubs de Eventos.

Próximos passos