Estabecimento de padroes para Base de Dados de Uso do Solo em escala provincial na China – parte 4: materializacao dos padroes
Seguindo o paper da semana, que vem da China, de autoria de Liao & Xu (J. of Geographic Information System, abril de 2010, v. 2), vamos agora falar da parte final do processo de padronização da base de dados de uso do solo em escala provincial.
O conteúdo dos padrões estabelecidos abrangeu:
- quais conteúdos serão remetidos;
- o formulário utilizado para remessa de dados;
- escopo da remessa (restrito a área administrativa da província);
- classificação, codificação e caracterização dos dados na base;
- regras de nomeação de arquivos;
- estrutura da base de dados;
- formulário de metadados; e
- formato de conversão de dados;
Alguns critérios técnicos adotados na padronização, como topologia (garantir consistência topológica da base de dados, como por exemplo, que dos polígonos vizinhos compartilhem a borda adequadamente). Outros critérios técnicos adotados foram a manutenção da série histórica de dados de uso do solo, adoção de regras de nomeação de arquivos também o processo de geração dos dados (o padrão se referia apenas ao processo de remessa). A classificação de dados pode ser personalizada desde que haja uma forma de remeter ao padrão definido (processo automatizado). Além disso, os objetos espaciais são divididos de acordo com o paradigma de representação vetorial, em primitivas de dimensão zero (ponto), 1 dimensão (linha) e 2D (área).
Para finalizar, quero mais uma vez destacar o que há, a meu ver, de mais relevante no estudo apresentado. A padronização é o caminho para o compartilhamento pleno e consistente de dados. O ideal seria que, por exemplo, que todo mundo adotasse o mesmo sistema de classificação de feições de uso do solo em nacional, e até internacional, ou pelo menos classiificações próprias que pudessem ser transformadas facilmente (de forma automática) num padrão convencionado de compartilhamento de dados. E a padronização pode ir tão longe quanto a adoção de convenções de simbologia, para facilitar, por exemplo, a integração de diferentes fonte de dados através de servidores de mapas via web (WMS/WFS).
Por: Rodrigo Sperb
Estabecimento de padroes para Base de Dados de Uso do Solo em escala provincial na China – parte 3: processo de padronizacao
Seguindo o paper da semana, que vem da China, de autoria de Liao & Xu (J. of Geographic Information System, abril de 2010, v. 2), vamos agora falar do processo de padronização da base de dados de uso do solo em escala provincial.
A primeira etapa compreendeu a análise de requisitos, onde a base de dados de uso do solo em escala provincial teve que ser completamente entendida quanto a complexidade de dados. Depois, a multiplicidade de dados de uso do solo em escala provincial teve que ser compreendida em sua completude, no que concerne plataformas de hadware e software. Isto foi seguido por uma investigação e análise dos recursos de dados e plataformas de sistemas existentes, para garantir que os padrões são independentes de software específico.
Posteriormente, os departamentos e setores relacionados a base de dados de uso do solo foram consultados, assim como especialistas puderam colocar suas considerações. Após algumas rodadas de revisão, o padrão estabelecido poderia então ser publicado.
No próximo post, veremos os principais aspectos do padrão estabelecido para a base de dados de uso de solo em escala provincial na China, cujo principal enfoque foi a remessa de dados. Até lá!
Por: Rodrigo Sperb
Estabecimento de padroes para Base de Dados de Uso do Solo em escala provincial na China – parte 2: principios de padronizacao
Seguindo o paper da semana, que vem da China, de autoria de Liao & Xu (J. of Geographic Information System, abril de 2010, v. 2), vamos agora falar dos princípios definidos para o processo de padronização da base de dados de uso do solo em escala provincial.
O primeiro princípio adotado é o de que os padrões devem orientar a classificação dos dados, armazenamento destes, e também o compartilhamento e transferência de dados. Outro é o da independência, o que significa que a estrutura da base de dados não pode ser baseada em nenhum plataforma de SIG ou aplicação.
O sistema deve ser capaz de se comunicar com a base de dados de uso do solo em escala nacional. A classificação de dados deve ser padronizada de acordo com os requisitos da situação atual, adotando padrões abertos.
No próximo post, veremos o processo de estabelecimento da padronização, as etapas envolvidas para realizar a base de dados de uso do solo em escala provincial, de acordo com os padrões definidos. Até lá!
Por: Rodrigo Sperb
Estabecimento de padroes para Base de Dados de Uso do Solo em escala provincial na China – parte 1: apresentando o problema
Eis um assunto que sempre me chamou a atenção na área de geoinformação. Reconhecendo a necessidade de compartilhar informações nos mais diversos níveis, tudo pode ir por água abaixo ou ser muito dificultoso se não tivermos padrões estabelecidos, tanto no que se refere ao desenvolvimento da base de dados, quanto ao compartilhamento propriamente dito deles.
O paper da semana vem da China, e estuda a questão de padronização de base de dados de Uso do Solo em escala provincial. Os autores são Liao & Xu, e o paper foi publicado no J. Of Geographic Information System, em abril de 2010 (v. 2). Os padrões a serem estabelecidos englobam a classificação de códigos de feições, divisão das camadas, regras de nomenclatura de arquivos, dados espaciais unificados, estrutura de dicionários e atributos de dados, formatos de conversão unificada e formatos de metadados, entre outros. Tudo para que as base de dados das diferentes províncias possam se comunicar entre si, e também com a base nacional já estabelecida.
Por: Rodrigo Sperb
Construindo funcionalidades para o WKT Raster
No post anterior, falamos um pouquinho sobre como o WKT Raster funciona. Hoje gostaria de mostrar um pouquinho sobre as maquinações que ando desenvolvendo para o PostGIS e WKT Raster.
Em tese, se o raster está armazenado no banco e conseguimos determinar o valor de cada pixel, poderíamos usar a SQL para realizar álgebra de mapas? A resposta é sim, podemos. É claro, já existem softwares especializados em realizar álgebra de mapas, como o IDRISI, ENVI, SPRING, ArcGIS (com Spatial Analyst), o módulo Sextante do gvSIG, WhiteBox, entre outros.
A vantagem de fazermos isto no PostGIS é que podemos aproveitar de algumas funcionalidades do banco de dados para realizar atualizações automáticas (funciona, mas a perfomance não deve ser das melhores), controlar melhor o acesso aos rasters - centralizando tudo em uma única localização, backup, etc.
Existem diversas funções para análise espacial de rasters, incluindo as matemáticas, lógicas, entre outras. Hoje irei mostrar apenas algumas matemáticas, que são bem simples. O módulo WKT Raster já planeja construir em C (linguagem nativa do PostgreSQL) algumas funções para análise espacial, mas enquanto isto não acontece, vamos levando com estas aqui.
Importante: estas funções só operam com rasters de uma única banda. Todas as operações são realizadas na banda 1. Nenhuma operação é realizada na banda 2 ou 3 - se bem que o suporte para tal é simples de ser construído.
Cuidado ao utilizar estas funções. Caso você sobreescreva seu raster, não o conseguirá de volta - caso precise.
ST_Plus
Esta função adiciona um valor double precision ao nosso raster de interesse. Se o pixel tem valor 1 e nosso argumento é 1, o resultado daquele pixel será 2. Esta função tem como entrada um raster e um valor numérico. O retorno da função é um objeto raster completo.
CREATE OR REPLACE FUNCTION ST_Plus(p_grid raster, z double precision) RETURNS raster AS $$ DECLARE w integer; h integer; z1 integer; grid raster; BEGIN SELECT ST_Width(p_grid), ST_Height(p_grid) into w,h; -- realizar cópia do raster original grid := p_grid; for i in 1..h loop for j in 1..w loop -- selecting cell value z1 := ST_Value(p_grid,i,j); grid := st_setvalue(grid,1,i,j,z1 + z); end loop; end loop; return grid; END $$ language 'plpgsql';
A função é bem simples. Ela copia o raster original em memória e adiciona o valor à cada pixel. Sem segredos. Como usá-la? Recomendo primeiramente, duplicar sua coluna do tipo raster, pois a função de adição de colunas raster é bastante longa e com parâmetros meio obscuros. Procure o arquivo SQL gerado pelo gdal2wktraster e ache a linha que adiciona a coluna. Modifique o nome da coluna e execute este comando novamente. Depois disso popule a coluna com os novos valores.
SELECT AddRasterColumn('public','teste_raster','grid_stplus',-1, ARRAY['16BUI'], false,
true, null, 0.000833, -0.000833, 9, 9,
ST_Envelope(
ST_SetSRID('POLYGON((-49.500416 -18.000416,-49.500416 -19.000416,-48.000416 -18.000416,-48.000416 -19.000416,-49.500416 -18.000416))'::geometry, -1)));
UPDATE teste_raster SET grid_stplus = ST_Plus('nome_da_coluna_raster_original',10);
Faça um teste com ST_Value para identificar se tudo correu bem. Neste teste, somamos 10 unidades ao valor de cada pixel da coluna original raster. Por que estamos criando uma coluna extra para armazenar nosso novo raster? Se alterarmos o raster original, não conseguiremos ele de volta, portanto, cuidado ao utilizar as funções.
ST_Minus
De forma similar à ST_Plus, ST_Minus vai subtrair determinado valor de cada pixel de nosso raster e nos trará como resultado o raster modificado.
CREATE OR REPLACE FUNCTION ST_Minus(p_grid raster, z double precision) RETURNS raster AS $$ DECLARE w integer; h integer; z1 integer; grid raster; BEGIN SELECT ST_Width(p_grid), ST_Height(p_grid) into w,h; -- realizar cópia do raster original grid := p_grid; for i in 1..h loop for j in 1..w loop -- selecting cell value z1 := ST_Value(p_grid,i,j); grid := st_setvalue(grid,1,i,j,z1 - z); end loop; end loop; return grid; END $$ language 'plpgsql';
Recomendo testar da mesma maneira que a função anterior. O uso é o mesmo - modificando o nome da função.
ST_Plus
Esta função realiza a multiplicação do valor do pixel. Simples e direta.
CREATE OR REPLACE FUNCTION ST_Times(p_grid raster, z double precision) RETURNS raster AS $$ DECLARE w integer; h integer; z1 integer; grid raster; BEGIN SELECT ST_Width(p_grid), ST_Height(p_grid) into w,h; -- realizar cópia do raster original grid := p_grid; for i in 1..h loop for j in 1..w loop -- selecting cell value z1 := ST_Value(p_grid,i,j); grid := st_setvalue(grid,1,i,j,z1 * z); end loop; end loop; return grid; END $$ language 'plpgsql';
Use-a do mesmo jeito que as anteriores.
ST_Divide
CREATE OR REPLACE FUNCTION ST_Divide(p_grid raster, z double precision) RETURNS raster AS $$ DECLARE w integer; h integer; z1 integer; grid raster; BEGIN if (z = 0) then return p_grid; end if; SELECT ST_Width(p_grid), ST_Height(p_grid) into w,h; -- realizar cópia do raster original grid := p_grid; for i in 1..h loop for j in 1..w loop -- selecting cell value z1 := ST_Value(p_grid,i,j); grid := st_setvalue(grid,1,i,j,z1 / z); end loop; end loop; return grid; END $$ language 'plpgsql';
ST_Power
Esta função eleva o valor da célula ao valor passado como parâmetro na função. Se temos uma célula de valor 2, e passamos 2 como parâmetro, teremos o 4 como resultado (2^2);
CREATE OR REPLACE FUNCTION ST_Power(p_grid raster, z double precision) RETURNS raster AS $$ DECLARE w integer; h integer; z1 integer; grid raster; BEGIN SELECT ST_Width(p_grid), ST_Height(p_grid) into w,h; -- realizar cópia do raster original grid := p_grid; for i in 1..h loop for j in 1..w loop -- selecting cell value if z = 0 then grid := st_setvalue(grid,1,i,j,1); else z1 := st_value(p_grid,i,j); grid := st_setvalue(grid,1,i,j,z1 ^ z); end if; end loop; end loop; return grid; END $$ language 'plpgsql';
E assim podemos construir funções que alterem nossos rasters originais. São funções simples, praticamente demonstrativas. Na sequência demonstraremos algumas funções mais interessantes, como declividade, cálculo de fluxo de direção, identificação de depressões, eliminação de depressões, entre outras.
Um abraço,
George R. C. Silva
Padrões Open Geospatial Consortium – Parte 2
Hoje vamos dar sequência à postagem sobre padrões da OGC. Na primeira postagem dessa série vimos o que é o OGC e alguns comentários sobre as especificações WMS, WFS e WCS.
Agora vamos tecer algumas considerações sobre os padrões GML, KML e SLD.
Geographic Markup Language (GML)
O objetivo da GML é oferecer um conjunto de regras com as quais um usuário pode definir sua própria linguagem para descrever seus dados, assim utilização do padrão GML permite a interoperabilidade entre dados geográficos. Definindo como será o armazenamento e transporte de informações geográficas, incluindo propriedades espaciais e não espaciais das entidades geográficas.
O GML é usado também em serviços WFS para trocar feições entre clientes e servidores, servindo, portanto como suporte ao serviço WFS.
Keyhole Markup Language (KML)
A linguagem XML (eXtensible Markup Language), como o próprio nome já diz, pode ser extendida ou ampliada. O próprio padrão KML da OGC é uma extensão de um XML utilizado pelo Google para tornar possível a visualização de dados geográficos nos seus famosos programas: Google Earth e Google Maps.
A estrutura do KML é baseado em tags como ocorre com arquivos HTML e XML comuns. Estas tags do KML tem os nomes e atributos usados para objetivos de exibição específicas. Em termos simples, notamos que o Google Earth e e o Google Maps funcionam pra os arquivos KML como como navegadores.
O KML depende de outros padrões para gerar a visualização de dados geográficos, pois na sintaxe do KML proveniente de um serviço de internet existe uma requisição WMS.
Hoje, o OGC e o Google trabalham em conjunto para aprimorar a implementação do KML, além de manter a comunidade informada das atualizações e avanços em seu projeto.
Styled Layer Descriptor (SLD)
A especificação SLD se refere à um arquivo XML que representa graficamente entidades geográficas (textos, pontos, objetos lineares ou polígonos.). Na linguagem SLD podem ser definidas regras que agrupam objetos em diferentes categorias e definindo para cada grupo um estilo diferente, por exemplo a simbologia de um WMS (estabelecer cores e rótulos) a partir de regras a serem definidas.
Programas de SIG, como o Udig, geram arquivos SLD de forma automática. Para executar este processo, basta adicionar uma camada WFS à uma visualização do Udig, fazer uma requisição ao servidor através de uma URL adequada e depois criar temas e rótulos de acordo com as necessidades da aplicação.
Enfim, esta foi uma breve consideração sobre alguns dos principais padrões da OGC (WMS, WFS, WCS, GML, KML e SLD). Espero que tenham gostado. Qualquer dúvida, entre em contato deixando um comentário.
Um Abraço e até a próxima postagem
--
Anderson Medeiros
Tecnólogo em Geoprocessamento
Consultor em Geotecnologias Livres
Padrões Open Geospatial Consortium – Parte 1
Olá Pessoal!
Hoje vou abordar um tema de extremo interesse para quem trabalha com Geotecnologias, livres ou não: Os padrões do Open Geospatial Consortium (OGC). Nesta primeira parte da série vamos entender o que é o OGC e os padrões WMS, WFS e WCS.
O Open Geospatial Consortium (OGC)
Desde seus primórdios em 1994 a instituição, que se chamava OpenGis Consortium, tem o com o objetivo de criar especificações de interfaces e padrões de intercâmbio de dados geoespaciais.
O OGC é hoje uma entidade internacional com mais de 350 companhias, agências governamentais e universidades, que tem o intuito de promover o desenvolvimento de tecnologias que facilitem a interoperabilidade entre diferentes sistemas que trabalhem com informação e localização espacial.
Asim, o OGC define especificações, ou padrões (como o WMS, WFS, WCS, etc) aos quais produtos e serviços precisam se adequar para que a interação entre diversas fontes de dados e informações espaciais seja facilitada, independente de fatores como a plataforma utilizada. A partir de agora vamos começar a compreender três das especificações do OGC.
Web Map Service (WMS)
O padrão WMS define um serviço para a produção de mapas que serão apenas uma representação visual dos dados espaciais e não os dados em si. Estas representações serão geradas no formato de imagem, como JPEG, PNG e GIF ou em formato vetorial, como o Scalable Vector Graphics (SVG).
Este padrão especifica como o cliente deve requisitar as informações para o servidor e como este deve responder ao cliente. As operações WMS podem ser realizadas a partir de um navegador comum que fará a submissão das requisições sob a forma de uma URL.
É importante destacarmos que o conteúdo da URL dependerá da operação solicitada. Em outras palavras, através da URL, indica-se qual a informação que deve ser exibida (região geográfica e dado de interesse), bem como o sistema de referência espacial, além das características da imagem de saída (altura e largura).
Web Feature Service (WFS) e Web Coverage Service (WCS)
A especificação de serviço WFS define um serviço para que clientes possam recuperar feições especiais em formato GML (você terá mais detalhes sobre GML na segunda parte desta série sobre o OGC). O WFS pode ser implementado pelo servidor em duas versões:
- Básica - Neste caso, basicamente funções de consulta ficam disponíveis, ou
- Transacional - Implementa o serviço completo, incluindo operações de inserção, deleção, edição e, claro, consulta à objetos espaciais.
Assim, podemos afirmar que o WFS apresenta maior interatividade que o WMS, pois este primeiro possibilita não apenas a visualização das feições geográficas, mas também sua manipulação.
Já o padrão WCS define o acesso aos dados que representam fenômenos com variação contínua no espaço. Este serviço é especificado para
tratamento de dados modelados como geocampos.
Breves Comparações entre WMS, WFS e WCS
Uma diferença marcante entre o WMS e o WCS é que este último retorna ao usuário dados sobre a semântica original dos fenômenos representados, ao invés de imagens. Em outras palavras, o WCS fornece os dados disponíveis de imagens, juntamente com detalhes descritivos sobre as mesmas, como a grade.
Já em uma comparação entre o WFS e o WCS notamos que o primeiro retorna os chamados geo-objetos, já no caso do WCS retorna geocampos, conforme mencionado anteriormente.
Assim, chegamos a conclusão de que o serviço WCS pode ser utilizada para enquadrar aplicações do Sensoriamento Remoto (pois em geral o SR está relacionado com geocampos) no contexto da interoperabilidade.
Conclusão e o que vem por ai
Dessa nossa breve análise sobre estes três dos diversos padrões do OGC podemos notar que cada um terá sua aplicabilidade, sendo interpretado e explorado de maneira diferente dependendo dos objetivos de seu projeto.
Programas como o gvSIG e o Udig permitem interações com webservices que sigam as especificações WMS, WFS e WCS.
Na segunda parte desse post veremos mais sobre as padrões da OGC, com ênfase nas especificações GML, SLD e KML.
Fiquem na expectativa...
--
Anderson Maciel Lima de Medeiros
Tecnólogo em Geoprocessamento
O Geoprocessamento e Suas Tecnologias – Parte 2
Olá!
Conforme vimos na primeira parte deste post, o Geoprocessamento é um conjunto de tecnologias dinâmicas com alto potencial de aplicação.
Até aqui vimos que Geoprocessamento e SIG não são as mesma coisa. O SIG é apenas uma importante tecnologia dentre as diversas incluídas no Geoprocessamento.
Vimos também que programas como o gvSIG e ArcGis não são "SIGs" mas softwares para SIG. Assim como o Geoprocessamento possui várias ramificações tecnológicas o SIG é um sistema composto por softwares, hardwares, metodologias, recursos humanos e dados.
Ficamos de ver o que são e pra servem tecnologias como o Banco de Dados Geográfico e o WebMapping.
Banco de Dados Geográficos
Bom, vamos por partes. O que é um Banco de Dados (BD)?
Todo local, físico ou virtual onde estão armazenados dados, pode em certo sentido, ser chamado de banco de dados. Por exemplo, uma enciclopédia pode ser considerada um banco de dados. Mas para nós aqui da área de Geoprocessamento é mais importante o conceito especial de banco ou base de dados relacional. Ou seja um banco onde dados são armazenados na forma de tabelas relacionáveis entre si através campos chaves.
As mais diversas facetas de atividades, desde locadoras de DVD até grandes indústrias metalúrgicas usam-se deste tipo de base para ter um maior controle sobre fatores como cadastro de clientes e sua condição em relação à empresa (Inadimplência, por exemplo).
Neste ponto, é importante evitar confundir o BD em sí (conjunto de tabelas relacionáveis) com o programa que o gerenciará, o Sistema Gerenciador de Banco de Dados (SGBD). EM outras palavras, softwares como Access, MySQL, Oracle, PostgreSQL não são BD, mas sim SGBD.
Mas ainda não falamos no assunto deste tópico. O que é e para que serve um Banco de Dados Geográfico (BDG)?
O BDG, também chamado de Banco de Dados Espacial (BDE), é semelhante ao descrito acima (relacional), com a grande e importante diferença de suportar feições geométricas em suas tabelas.
Este tipo de base com geometria oferece a possibilidade de análise e consultas espaciais. É possível calcular nestes casos, por exemplo, áreas, distâncias e centróides, além de realizar a geração de buffers e outras operações entre as geometrias.
Como dica de estudos para você obter uma boa base conceitual sobre BDG, indico o livro "Banco de Dados Geográficos" do INPE, que está disponível para download em PDF aqui.
Atualmente, alguns programas de SGBD desenvolveram extensões que inserem no software características de Sistemas Gerenciadores de Banco de Dados Geográficos (SGBDG) o PostgreSQL, MySQL, e Oracle, sendo os dois primeiros softwares livres e o último proprietário.
Vamos falar um pouco mais do PostgreSQL e como ele passa a agir como SGBDG. O PostgreSQL é desenvolvido atualmente pela PostgreSQL Global Development Group. Quando se percebeu a necessidade de extender este SBGD para suportar dados espaciais desenvolveu-se a extensão conhecida como PostGis.
Sendo assim, vamos entender que o PostGis não é um BDG ou um SGBDG, ele é apenas uma extensão, um plugin, do PostgreSQL que lhe confere funções para armazenamento e manipulação de dados geográficos.
A figura abaixo procura mostrar a diferença entre o PostgreSQL e "seu filho". Note que para termos um BDG no PostgreSQL faz-se necessária a devida instalação da extensão PostGis.
Você pode importar arquivos vetoriais shapefile (*.shp) para dentro de um "Banco PostGis" utilizando recursos oferecidos pelo próprio programa ou utilizando algum software de SIG com essa funcionalidade. O shapefile será convertido em uma tabela espacial que pode ser integrada com as convencionais contidas na base, além de poder ser visualizada e manipulada através de programas como o gvSIG, Kosmo, Quantum Gis, Udig e muitos outros desta safra. Para baixar tutoriais sobre como realizar esta operação com alguns destes softwares, clique aqui.
Para baixar a versão mais recente do PostgreSQL e sua extensão espacial PostGis, acesse os links abaixo.
Para finalizar este post vamos considerar outra tecnologia do Geoprocessamento, a saber, WebMapping.
WebMapping (WebGis)
A internet vem se destacando nos últimos anos como uma excelente ferramenta para disponibilização e interligação de dados das mais diversas fontes e naturezas.
A geomática, como área do conhecimento, também encontrou na internet um nicho para suas atividades. A disponibilização de mapas digitais, os chamados WebGis ou WebMapping, tem-se tornado comum, permitindo que um maior número de usuários tenha acesso a dados espacializados, de forma hábil e atraente.
Talvez o estopim para o crescimento das aplicações SIG para internet tenha sido a popularização de serviços online gratuitos de localização como o Google Earth e Google Maps.
Os mapas na web se apresentam de três formas princiapais:
1) Mapas Estáticos - Mapas no formato de imagem (*.jpg, *.gif, *.png, etc) integrados à páginas da internet.
2) Mapas Gerados à partir de formulários - Fornece-se parâmetros para geração de mapas na forma de imagem.
3) Mapas Dinâmicos - O usuário seleciona uma área de seu interesse em um mapa geral, gerando uma navegação para outro mapa ou imagem mais específico com informações mais detalhadas desta região. Em geral apresentam interface atraente com ícones para consulta espacial calculo de distância e etc.
Para mais detalhes sobre tipos de mapas veja a publicação disponibilizada neste link.
Há muitos softwares e frameworks livres para o desenvolvimento de aplicações WebGis. Podemos destacar alguns: MapServer, GeoServer, i3Geo, Alov Map, Time Map, Open Layers e P.Mapper.
Diversos órgãos públicos fazem uso destas ferramentas para divulgação dos resultados de seus trabalhos.
A imagem abaixo mostra um exemplo de aplicação desenvolvida com MapServer e o framework P.Mapper. Clique aqui para acessar a página da aplicação (Este é um exemplo de mapa dinâmico).
Nesta visão geral sobre algumas das tecnologias do Geoprocessamento, pudemos dissipar alguns falsos conceitos em torno de termos como SIG, BDG, SGBDG, WebGis, etc. Espero que tenham gostado do que leram.
Fiquem à vontade para deixar sua sugestão de tema, críticas e impressões através do e-mail anderson[@]geoprocessamento.net
Anderson Medeiros
Tecnólogo em Geoprocessamento
Sql Server 2008 e o sistema de uma projeção só
Boa noite pessoal,
Estava trabalhando em alguns assuntos no Sql Server 2008 e até aí tudo bem. Tinha alguns dados em outro banco de dados, representativos de pontos. Tudo UTM SAD69. O banco do GIS em Lat/Long SAD69.
As tabelas eram mais ou menos assim:
CREATE TABLE foo ( id SERIAL NOT NULL, x DOUBLE PRECISION NOT NULL, y DOUBLE PRECISION NOT NULL, z DOUBLE PRECISION NOT NULL, sistema_coordenada VARCHAR(20) NOT NULL,0 -- etc );
Sempre com diversos pontos e diversos sistemas de coordenadas.
Bem, a idéia era montar uma visão no banco de dados, registar a parada com o ArcSDE, e disponibilizar os dados que eu queria em tempo real para os usuários do GIS, inclusive eu.
Liguei em uma certa empresa que comercializa um certo software, no suporte. Expliquei a situação, perguntei se o rapaz ou alguém lá saberia de uma solução para realizar o idealizado. De forma alguma (eu) estava viajando na maionese, pela minha experiência (que não é muita) com o PostGIS, sabia que era fazível.
O certo indivíduo que me atendeu, deve ter feito uma cara do outro lado de "What the hell?" sugeriu que eu jogasse minha tabela no ArcMap e rodasse um XY para plotar os dados. Valeu pela super dica amigão. Se você ler isto e lembrar de mim sabe que existe uma forma!
Mas vamos lá. O PostGIS, que é um tanto mais avançado que o Sql Server 2008 nesses quesitos, bastaria o seguinte para criar uma visão espacial (com um ponto de verdade, e não um par de coordenadas) e transformar a parada para o datum que eu queria:
CREATE OR REPLACE VIEW view_foo AS
SELECT ST_Transform(ST_Point(X,Y),4618), coluna1, coluna2 from foo;
Bem, simples né? Acontece que o SQL Server 2008 NÃO POSSUI funções nativas para conversão de coordenadas/projeção de um sistema para outro.
Um camarada do trabalho, Danilo, me falou que já havia visto no CodePlex, um site com um repositório de código da Microsoft, um projeto que realizava o serviço. Bem, o projeto, Sql Spatial Tools, tem muita utilidade e outras funções, como agregador de geometrias, mas as funções de conversão de coordenadas estava furada. Pelo menos a que nós precisávamos usar.
Lembrei que o PostGIS, que também não tem esta capacidade nativa, mas é fornecida pela Proj4, e talvez poderíamos utilizar a Proj4. Mais uma busca no Codeplex e achamos a ProjNET, uma adaptação da Proj4 (acho que é escrita em C) para .NET, em C#.
Utilizamos o modelo da Sql Spatial Tools para registrar bibliotecas externas (muito top, parabéns Sql Server, muito tetinha de fazer) e para expor uma única função que criamos para o Sql Server. A ProjNET, ao contrário da Sql Spatial Tools, realmente converte as coordenadas.
Dicas
-
Sempre olhe no Codeplex.
-
Para registrar uma dll externa (dentro do Sql Server) utilize (isto é código SQL): CREATE ASSEMBLY ProjNet 'caminhoParaDll'
-
Para registrar uma função: CREATE FUNCTION nomeFuncao (parametros) returns tipoRetorno AS external ProjNet.Namespace.Funcao
É só.
No final nossa idéia ficou similar a do PostGIS, and it works. Resultado: utilizamos os dados que temos, sem a necessidade de administrar/atualizar FeatureClasses e realizar tarefas tediosas de Add XY data-Project Data e propensas à erros. E o melhor de tudo, é tudo em tempo real. Se o outro sistema for atualizado às 10:01:01:0001, nós iremos ver os dados atualizados às 10:01:01:0002.
Lições aprendidas
-
Novamente, sempre olhe no CodePlex.
-
É muito fácil desenvolver/linkar APIs e outros frameworks ao Sql Server 2008.
-
Nunca, nunca confie no suporte técnico oferecido.
Thank you notes/Agradecimentos
Danilão! Pelo tempo gasto nisso e paciência.
Onald McDonald e Ogerio McDonald, pela torcida.
Ed Katibah, lead developer at Microsoft, who exchanged several emails with me and noticed that their implementation of Sql Spatial Tools is not correct (for UTM projections), and opened a ticket for fixing. Soon Sql Spatial Tools will be ready to handle all conversions.
Contribuindo um pouquinho…
Boa noite pessoal,
Alguns dias atrás me cadastrei no trac da OsGeo para ver se conseguia solucionar algum tiquete em aberto.
Para quem não sabe, trac é um sistema que controla as informações sobre bugs, melhoramentos entre outras coisas à fazer, dentro de um projeto de software. Ele permite um usuário aceitar uma tarefa, postar arquivos e mensagens e receber comentários em seu trabalho.
Aceitei o tíquete #180 que pede a criação de algumas funções para criar tabelas "históricas", permitindo o usuário saber quem alterou a tabela, como alterou, quando e todas as alterações feitas. À partir daí ele tem opções de restaurar uma feição que foi deletada ou editada de forma errada, entre outras coisinhas.
Montei algumas funções em pl/pgsql puro para gerar estes códigos, e as mesma estão disponíveis no link mostrado acima. Ainda existe muita discussão à ser feita para que elas comecem a pertencer ao código "oficial" do PostGIS, mas está caminhando. PS do dia 13/01/2010 - o patch foi aceito e já foi comitado em trunk. Provavelmente seu PostGIS já vem com o módulo, com algumas mudanças. Não deixe de conferir!
O bacana, além de aprender e conhecer gente nova, é poder devolver um pouco pra um software excelente. Uma contribuição pequena, com certeza, mas que mais pra frente pode ajudar muita gente.
George Silva
