GDAL é uma biblioteca de código aberto amplamente utilizada para ler e escrever um grande número de formatos de dados espaciais raster. Com origem em 1998, a biblioteca evoluiu consideravelmente. Ele suporta seu próprio modelo de dados e interface de programação de aplicativos (API). Desde a origem inicial de desenvolvimento único, o GDAL se desenvolveu em um projeto distribuído com um número relativamente grande de desenvolvedores.
Para o conceito de GDAL, pode ser um pouco confuso. GDAL é a abreviação de Geospatial Data Abstraction Library.No início, era uma biblioteca de classes usada para processar dados espaciais raster, enquanto OGR era usada para processar dados vetoriais. Posteriormente, as duas bibliotecas foram fundidas em uma e o nome GDAL foi usado no download e na instalação. Por razões históricas, os dois tipos de bibliotecas são mantidas pelo mesmo sistema de geração. O mais importante é que o autor da GDAL/OGR é a mesma pessoa, que também é o presidente da OSGeo, Frank Warmerdam, que há muito famoso no campo de OpenSource Geospatial. Muitos programadores leem seu código para entender a essência do software de informação espacial.
Os dados são o sangue do software, especialmente na indústria de informação espacial. Dados massivos são mais evidentes na indústria de software de informação espacial. Sem um conjunto de modelos eficientes de conversão de dados e bibliotecas de classe, é difícil completar a integração e fusão de dados heterogêneos Com GDAL/OGR, todos os tipos de projetos de software de informação espacial baseados nele têm vitalidade.
GDAL/OGR é escrito em linguagem C++ orientada a objetos, o que faz com que a biblioteca tenha alta eficiência de execução enquanto suporta mais de cem formatos. GDAL/OGR também fornece ligações para várias linguagens de programação convencionais. Além das linguagens C e C++, os usuários também podem chamar GDAL em Perl, python, VB6, Ruby, Java, C# e outras linguagens, o que torna a aplicação de GDAL mais fácil. muito amplamente. O projeto GDAL mantém as ligações GDAL/OGR para Python geradas usando SWIG. No geral, classes e métodos em Python correspondem aproximadamente a classes em C++. Na versão mais recente do GDAL 1.9.0, o GDAL oferece suporte a mais de 120 formatos de dados raster e, na próxima versão, os formatos de dados suportados chegarão a 200. Nas configurações de opção de compilação padrão do GDAL, alguns formatos de dados criam arquivos diretamente e executam o registro geométrico neles.
Como o GDAL fornece suporte para vários formatos de dados raster, muitos softwares o utilizam como a biblioteca de processamento de dados subjacente. Os mais famosos são: ArcGIS, Google Earth, OpenEV, GRASS GIS, OSSIM, Quantum GIS, MapServer, World Wind.
modelo de dados GDAL
O modelo de dados GDAL consiste em muitas partes, cada uma das quais suporta a filosofia básica de design da biblioteca descrita acima. Essas partes são discutidas nas seções a seguir.
No modelo GDAL, existem três conceitos importantes: conjunto de dados, banda raster e tabela de cores. Entre eles, o conjunto de dados, a banda raster e a tabela de cores nada têm a ver com o conceito de GIS, mas apenas definem como os dados raster são exibidos em cores.
Conjunto de dados GDAL
Um conjunto de dados (representado pela classe de conjunto de dados GDAL) é uma coleção de bandas raster relacionadas e algumas informações associadas. Esse tamanho de raster do conjunto de dados se aplica a todas as bandas. Este conjunto de dados também é responsável pela definição do georreferenciamento e definição do sistema de coordenadas para todas as bandas. Os próprios conjuntos de dados também têm metadados associados, armazenados como strings em listas de nomes/valores, conforme a seguir.
Conjuntos de dados GDAL e modelos de dados de banda raster são definidos com base no formato OGC.
sistema de coordenadas
Os sistemas de coordenadas do conjunto de dados GDAL são expressos em strings OGC WKT. Incluir:
- Nome completo do sistema de coordenadas
- Nome do sistema de coordenadas geográficas
- Dado
- Nome do elipsóide, semi-eixo maior, deflexão inversa
- O nome do meridiano principal e seu deslocamento de Greenwich
- Tipo de método de projeção (por exemplo, Transverse Mercator)
- lista de parâmetros de projeção (por exemplo, meridiano central)
- O nome da unidade de medida, convertido em metros ou radianos.
- O nome e a ordem dos eixos.
A maior parte do código para os sistemas de coordenadas predefinidos acima vem do European Petroleum Survey Group (EPSG) ( http://www.epsg.org/).
Uma string de sistema de coordenadas vazia indica que não se sabe qual sistema de coordenadas de georreferenciamento está sendo usado.
Transformação Geográfica Afim
Os conjuntos de dados GDAL têm dois métodos para representar a relação entre localizações raster (pixel ou coordenadas de linha) e coordenadas georreferenciadas. A transformação afim mais comumente usada. A transformação afim consiste em seis parâmetros, GDALDataset::GetGeoTransform()retornados por , para converter coordenadas de pixel/linha em espaço georreferenciado usando a seguinte relação:
$$ Xgeo = GT(0)+Xpixel{\cdot}GT(1)+Yline{\cdot}GT(2) \\\\ Ygeo = GT(3)+Xpixel{\cdot}GT(4)+Yline {\cdot}GT(5) $$
Na imagem "Northward", os coeficientes GT(2) e GT(4) são 0, GT(1) é a largura em pixels e GT(5) é a altura em pixels. A posição (GT(0), GT(3)) é o canto superior esquerdo do pixel superior esquerdo do raster.
Observe que as coordenadas de pixel/linha acima vão do canto superior esquerdo do pixel superior esquerdo (0,0, 0,0) ao canto inferior direito do pixel inferior direito. Por exemplo, a posição central do pixel superior esquerdo é (0,5, 0,5).
ponto de controle geográfico
Uma das maneiras pelas quais o GDAL descreve a georreferência de conjuntos de dados raster é usando Pontos de Controle Geográfico (GCPs). Usando esta abordagem, um conjunto de dados terá um conjunto de pontos de controle, localizações raster associadas e uma ou mais localizações em um sistema de referência geográfica. Todos os pontos de controle compartilham um sistema de coordenadas georreferenciadas ( GDALDataset::GetGCPProjection()retornado por ). Cada ponto de controle (descrição da classe GDAL-GCP) consiste nas seguintes partes (em linguagem C):
- Char pszId
- Char pszInfo
- duplo dfGCPPixel
- duplo dfGCPLine
- duplo dfGCPX
- duplo dfGCPY
- duplo dfGCPZ
A string pszid é um identificador exclusivo (geralmente, mas nem sempre numérico) para o GCP no conjunto de pontos de controle no conjunto de dados. Normalmente, pszinfo é uma string vazia, mas pode conter qualquer texto definido pelo usuário associado ao ponto de controle. Potencialmente, isso também pode conter informações analisáveis por máquina sobre a máquina de estado do GCP, embora esse seja um recurso que ainda não foi implementado. Em pixels, a posição da linha é a posição do ponto de controle na grade. A localização X,Y,Z é relativa à localização georreferenciada (o valor Z geralmente é zero).
O modelo de dados GDAL não implica que os mecanismos de transformação devam surgir de pontos de controle, mas são deixados para o aplicativo. No entanto, polinômios de grau 1 a 5 são métodos comumente usados. Normalmente, os conjuntos de dados contêm transformações afins ou pontos de controle geográficos ou nenhum deles. Existem relativamente poucos casos em que ambos estão disponíveis e não foi determinado qual método é mais confiável.
metadados
Os metadados do GDAL são um formato auxiliar no qual os dados textuais específicos do aplicativo são armazenados como uma lista de pares nome/valor. Os nomes precisam ser bem marcados (sem espaços ou caracteres estranhos). Os valores podem ter qualquer comprimento e podem conter qualquer valor, exceto null incorporado (ASCII0).
Alguns formatos oferecem suporte a alguns metadados definidos pelo usuário, enquanto os drivers para outros formatos mapearão campos específicos do formato para nomes de metadados. Por exemplo, o driver TIFF retorna algumas tags de informações, pois os metadados incluem um campo de data/hora, retornado assim:
TIFFTAG DATETIME=1999:05:11 11:29:56
Os metadados também podem ser divididos em grupos chamados domínios, o domínio padrão não tem nome (NULL ou ""). Alguns campos específicos existem para fins especiais. Observe que, embora atualmente não haja como enumerar todos os campos de um determinado objeto, os programas podem testar qualquer campo que saibam interpretar. Um exemplo é o campo SUBDATASETS, descrito na próxima seção.
campo de subconjunto de dados
O domínio do subconjunto de dados contém uma série de subconjuntos. Normalmente, isso é usado para fornecer ponteiros para sequências de imagens armazenadas em arquivos de várias imagens (HDF ou NITF). Por exemplo, um NITF com quatro imagens pode ter a seguinte lista de subconjuntos:
SUBDATASET_1_NAME=NITF_IM:0:multi_1b.ntf
SUBDATASET_1_DESC=Image 1 of multi_1b.ntf
SUBDATASET_2_NAME=NITF IM:1:multi_1b.ntf
SUBDATASET_2_DESC=Image 2 of multi_1b.ntf
SUBDATASET_3_NAME=NITF IM:2:multi_1b.ntf
SUBDATASET_3_DESC=Image 3 of multi_1b.ntf
SUBDATASET_4_NAME=NITF IM:3:multi_1b.ntf
SUBDATASET_4_DESC=Image 4 of multi_1b.ntf
SUBDATASET_5_NAME=NITF IM:4:multi_1b.ntf
SUBDATASET_5_DESC=Image 5 of multi_1b.ntf
Uma string terminando com NAME pode ser passada GDALOpen()para acessar esses arquivos. Valores que terminam em DESC são strings amigáveis que exibem uma lista de opções para o usuário.
banda raster
As bandas raster GDAL são representadas usando a classe GDALRasterBand. Representa uma banda raster, canal ou camada. Geralmente não representa uma imagem inteira. Por exemplo, uma imagem RGB de 24 bits geralmente é representada como três bandas, vermelho, verde e azul. Uma banda raster tem as seguintes propriedades:
- A altura, largura e número de linhas da célula. A definição do conjunto de dados é a mesma se for uma banda de resolução total.
- Tipo de dados (GDALDataType). Um byte, UInt16, Int16, UInt32, Int32, Float32, Float64, tipos complexos CInt16, CInt32, CFloat32 e CFloat64.
- tamanho do bloco. Este é o tamanho de bloco de acesso preferencial. Para imagens lado a lado, esta é uma fatia. Para imagens de linha de varredura, geralmente é uma linha de varredura.
- A lista de metadados dos pares nome/valor está no mesmo formato do conjunto de dados, mas as informações são por banda.
- String de descrição opcional.
- Uma lista opcional de nomes de classe (nomes de classe válidos para imagens de tema).
- Valores máximos e mínimos opcionais.
- Deslocamento e escala opcionais para converter valores raster em valores significativos (por exemplo, converter altura em metros).
- O nome da unidade de grade. Por exemplo, os dados de elevação podem estar em unidades lineares.
- A interpretação das cores das bandas. Isso pode ser indefinido, cinza, índice de paleta, vermelho, verde, azul, alfa , matiz, luminosidade de saturação, ciano, magenta, amarelo e preto.
- Um mapa de cores, detalhado na próxima seção.
- Conhecimento de visões gerais de resolução reduzida (pirâmides), se disponível.
tabela de cores
Uma tabela de cores contém 0 ou mais cores, representadas por uma estrutura em código C:
- short C1; /* cinza, vermelho, ciano ou matiz */
- C2 curto; /* verde, magenta ou claro*/
- C3 curto; /* azul, amarelo ou saturado */
- C4 curto; /* alfa ou
blackband*/
Um valor de interpretação da paleta (GDAL PaletteInterp) é exibido na tabela de cores, que é um dos seguintes valores indicando como os valores na tabela de cores são interpretados. Os valores são Gray, RGB, CMYK e HLS.
Vincule pixels raster a cores e os valores de pixel são usados como subscritos na tabela de cores. Ou seja, as cores sempre começam do zero, em ordem crescente. Nenhum mecanismo de pré-ajuste é fornecido antes de olhar para o mapa de cores.
olhada rápida
Uma banda pode conter uma ou mais visões gerais. Cada um representa um GDALRasterBand relativamente independente. O tamanho da visualização rápida é diferente do raster subjacente, mas as bandas de georreferenciamento e resolução total da visualização rápida são as mesmas. As visões gerais podem exibir imagens de resolução mais baixa muito mais rapidamente do que ler imagens de resolução total e redimensioná-las.
conceito de design
A origem do GDAL é a necessidade de conversão de formato de arquivo eficiente e flexível, e o GDAL introduz extensões para novos formatos, nem exclui quaisquer decisões de design específicas frequentemente encontradas em formatos de dados espaciais. Portanto, a intenção do projeto era originalmente alcançar cobertura onipresente por meio de um modelo de dados abstrato unificado e padrões em consideração, ou publicados por organizações como o Geospatial Consortium (OGC). Esses e outros princípios de design são discutidos nas seções a seguir.
Um modelo de dados abstrato unificado
Uma importante lição aprendida na experiência do PCI com o GDB é ter um modelo de dados abstratos bem definido que implemente o GDAL. Para GDAL, este é um modelo abstrato: possivelmente incluindo conjuntos de dados raster, ou seja, tipos de dados de pixel, modelos de metadados, modelos de cores, mecanismos de georreferenciação, etc.
No entanto, nem todos os drivers de formato de dados podem implementar todos os aspectos do modelo de dados abstrato, mas o próprio modelo de dados é um modelo virtual generalizado aplicado a todos os conjuntos de dados adequados para o formato. O modelo de dados será descrito em mais detalhes abaixo.
Cooperando com o Open Geospatial Consortium
Na prática, GDAL adota o padrão OCG. Como o OGC não especifica o padrão API C++, geralmente não assume a forma de implementação direta da especificação OGC, mas adota o modelo de dados e o tipo de dados ajustados do OGC:
OGC Simple Feature Geometry: A OGC Simple Feature Specification, como SQL Simple Feature, descreve uma geometria vetorial do Sistema de Informação Geográfica (GIS), bem como os modelos de codificação Well Known Text (WKT) e Well Known Binary (WKB).
Sistema de Referência Espacial do OGC: Os recursos simples do OGC também descrevem um mecanismo WKT para descrever sistemas de coordenadas ou projeção. Esta representação é adotada pelo GDAL como uma representação interna de seu sistema de coordenadas. Este padrão é semelhante à string do mecanismo de projeção da ESRI para arquivos shapefile.Prj.
Grid Coverage: Um modelo é definido para conjuntos de dados raster na especificação OGC Grid Coverage. Até certo ponto, é usado como modelo em termos de API GDAL. GetCategoryNames的getOffset() , GetScale() e GetColorInterpretation() os métodos podem ser rastreados até a especificação de cobertura OGC.
Configuração zero - apontar e abrir
Outros designers com experiência em GDB tentam garantir que a abertura do conjunto de dados seja a mais simples possível. Em particular, os usuários não devem saber o formato do arquivo com antecedência ou precisam definir opções antes de abrir o conjunto de dados. Deve ser algo tão simples quanto selecionar um arquivo e ver se ele é reconhecido pelo software.
No GDAL funciona assim, tem uma série de drivers de formato, cada um (na ordem) é usado para tentar importar um conjunto de dados. O primeiro bem-sucedido é usado para abrir o arquivo. Drivers individuais podem identificar formatos por strings reconhecidas em cabeçalhos de arquivos, extensões ou, em alguns casos, prefixos especiais embutidos em conjuntos de dados. No entanto, o ponto chave é que o usuário geralmente pode abrir o arquivo usando "Arquivo > Abrir" no menu, e o usuário pode não ter conhecimento prévio do arquivo a ser aberto.