Metadata, parte 2: o que catalogar e não catalogar?

Noches, meus queridos leitores.

Continuaremos falando sobre metadata.

Como os metadados devem ser coletados? Qual é o grau de padronização destes elementos? Quem deve coletar estes dados? O produtor dos dados? O usuário final? Ou alguém entre os dois?

Existem diversos debates sobre como estes procedimentos devem ocorrer, mas de forma geral, os metadados são coletados com uma relação 1:1. Um dataset, ou um conjunto de feições deve ter, obrigatoriamente um registro nos metadados. Mas como definimos o que é um conjunto?

Para responder esta pergunta, primeiramente precisamos analisar o que iremos documentar. São uma série de fotografia pertencentes à um artigo? Ou é uma série de fotografias pertencentes à diversos artigos, relacionados pelo tema? É uma imagem de satélite, um mosaico ou um conjunto de relatórios gerenciais, com mês, escopo e informações correlacionadas?

Bem, após identificarmos o objeto (ou conjunto de objetos) devemos definir uma raiz comum aos mesmos. Podemos criar metadados para diversos níveis de informações: uma imagem bruta de satélite, um mosaico de imagens, um conjunto de vetores específico e até mesmo feições específicas. Perceba, que conforme especializamos a coleta de metadados, o número de informações também aumenta, por devemos manter a relação 1:1 mencionada acima. Um objeto (seja ele um conjunto de outros objetos) deve ter seus registros de metadados, e isto deve ser aplicado à todos os registros de suas bases.

Não adianta nada documentarmos determinados objetos em um nível e outros não. Seria como (no exemplo da Biblioteca Nacional, do post anterior) ter 1000 caixas com livros diversos e apenas 100 delas descritas no conteúdo.

Este planejamento é importante, pois não queremos informação demais, nem de menos. Informação, na verdade, nunca é demais, mas o custo para a criação de metadados muito detalhados é muito mais caro. Deve existir um balanço entre o que documentar, e o que não documentar.

Na prática, a maior parte dos dados é coletado no nível de datasets, ou seja, no conjunto, e não na particularidade. Um conjunto de imagens SRTM não devem ser catalogadas individualmente (existem dados interessantes para catalogarmos, como a altitude mínima e máxima, coordenadas geográficas, entre outros), mas sim no conjunto de processamento.

Caso os dados SRTM seja processados (interpolados, por exemplo), deve se criar um novo dataset, e catalogá-lo à partir daí.

Agora, quem deve catalogar os dados? O produtor dos dados? O usuário final?

É outra briga de muitas perspectivas. O produtor dos dados, obviamente deve realizar um cadastro minucioso dos processos utilizados para gerar aquela informação. Mas o usuário final, o indivíduo que requisitou aquela informação, tem a capacidade de complementar os metadados, já que somente ele sabe como aqueles dados serão efetivamente utilizados.

Criar metadados é bem parecido com catalogar livros em uma biblioteca. Quem deve realizar este procedimento dentro de sua empresa? Uma pessoal especialmente contratada para isto? (bem, é forçar um pouco a barra, já que muito poucas empresas darão um braço à torcer para um funcionário extra, só para catalogar "mapinhas"). Em geral, os próprios analistas devem catalogar seus dados, mas a maioria dos profissionais pode chiar, alegando que:

• É muito difícil produzir metadados;
• Não veêm os benefícios dos metadados;
• Não existe tempo suficiente para a produção dos metadados;

Bem, todos os casos acima são argumentos razoavelmente válidos, mas facilmente desmantelados por um profissional com conhecimento técnico, pois:

• Produzir metadados exige cuidado e paciência. Mas não é um procedimento difícil. É trabalhoso.
• Quando sua base de dados chegar a uma centena de datasets, ele irá pedir tempo para criar os metadados. Bases de médio porte, com centenas de datasets não são incomuns.
• Um pouquinho de tempo por dia, vinte minutos, meia hora por dia é suficiente para uma pequena equipe atualizar todo o cadastro de metadados de uma base razoavelmente grande. Será que a perda de tempo de um dia inteiro na criação dos metadados para um dataset coletado ao longo de diversos meses é realmente uma perda de tempo? Com certeza não é.

Claro, coletar uma quantidade muito grande de metadados ao mesmo tempo pode ser enfadonho e moroso, portanto o ideal é coletar os metadados aos poucos, conforme os dados são produzidos/inseridos dentro do banco de dados.

Certo, certo, mas qual é a forma de criar e manter um catálogo de metadados para seus dados geográficos? Isto depende de alguns fatores: tamanho da organização, tamanho e diversidade dos dados geográficos e basicamente de gerência departamental.

Pode-se começar de forma pequena, utilizando pequenos documentos formato texto ou utilizar XML. Atualmente existem diversos padrões (falaremos deles depois) que podem ser seguidos, que auxiliam o usuário a criar seus metadados. A maioria dos programas de GIS possuem módulos específicos para a criação e manutenção dos metadados. O ArcGIS possui um módulo embutido no ArcCatalog. Para os utilizadores OpenSource, ou quem não gosta do administrador de metadados do ArcGIS/outros programas proprietários podem utilizar o GeoNetwork, um programa desenhado especificamente para este propósito.

Outros caminhos para o armazenamento dos metadados é o uso de um banco de dados ou arquivos estruturados em XML, que é a maneira mais comum atualmente. Somente grandes sistemas e organizações conseguem migrar todos os metadados para um ambiente relacional, mas não deveria ser assim. Aplicações tem de ser desenvolvidas para suprir essa deficiência. Algumas, como o GeoNetwork já existem.

Duas dicas importantes:

• Não invente seu próprio modelo de metadados (já existem vários! um deve servir para você. reiventar a roda é (na maioria dos casos) perda de tempo)
• Não confunda a apresentação dos metadados com os metadados. Como já diziam, uma coisa é uma coisa, e outra coisa é outra coisa. A capacidade de traduzir os dados brutos em informação real (como relatórios de "estoque" de dados geográficos) é vital para o sucesso dos metadados.
  

Esta, como disse, é uma discussão praticamente sem fim, pois através dos metadados podemos simplificar de forma exponencial o trabalho e os retrabalhos com nossos dados espaciais. Buscar dados existentes (especialmente em grandes organizações), catalogar as novas informações e publicar isto aos usuários dá agilidade, confiança e principalmente economia de recursos (humanos e capital financeiro).

Na próxima ediçao, padrões de metadados.

Abraços

Metadata: uma pequena introdução e comentários aleatórios

Boa noite pessoal,

Conforme solicitado pelo nosso amigo Anderson, um post (ou uma série) sobre metadata.

Comecemos pelo começo: o que é metadata. Do mesmo jeito que nossa professora de quarta série nos ensinou que "geografia": geo - terra, grafia - escrita, descrição, era o estudo e descrição da Terra, seus habitantes e fenômenos.

Vamos começar pela etimologia da palavra: metadata, metadados, conforme preferirem. Do dicionário online de Etimologia:

meta- 1: atrás; 2: alterado; 3: maior, além; 4: no meio, entre, com sujeito (ah, tudo isso vem do grego)

meta + data(dado) = dado alterado, modificado? dado...por trás do dado?

Metadata ou metadados significa isto, dados dos dados. Informações sobre os dados.

Certo, mas pra que quero mais informação? Dados sobre os dados? Ah sim, é uma pergunta comum. Bem, vou tentar explicar por que os metadados são importantes.

Primeiramente, eles descrevem os dados para você, sem que você tenha que olhar o que cada um é, um por um. Só nessa temos uma grande vantagem. Ao invés de procurar todos os seus dados, procuramos no metadata, no catálogo. Ah, então os metadados são catálogos? Quase isso. O catálogo é uma coleção de metadados.

Um exemplo comum de metadados são as etiquetas de um livro, na biblioteca. Eles descrevem o assunto, categorizam o livro, título, autor, edição, entre outras informações importantes. Outro exemplo de metadados:

 

Como informação/conhecimento é poder, conhecer seus dados é poder. Atualmente, todos nós geramos imensas quantidades de informação e dados. Certo, mas do que adianta possuir a Biblioteca Nacional em casa se todos os livros estão em caixas? Como achar o livro que você precisa, na caixa certa, no momento certo?

Sem um sistema de catálogo, sem os metadados organizados, achar este determinado livro não é possível. Não sem abrir todas as caixas :D.

Outra coisa, metadado é contexto. Dados sem contexto não tem nem a metade do valor de dados contextualizados. A documentação de como aquele dado foi obtido, produzido, processado, armazenado é extremamente valiosa, e sem ela, podemos inviabilizar quaisquer possibilidade do uso das informações.

Imagine a seguinte tabela:

LINHA | NOME | TIPO | LARGURA

Estamos falando de estradas, rios e córregos, sistemas de transmissão de energia (ah, ontem acabou a luz no Brasil inteiro, vocês viram?) ou logradouros? Estamos falando de metros, kilometros, centímetros? Claro que este é um exemplo bobo, mas imagine um sistema gigantesco, com milhares e milhares de tabelas, shapefiles, arquivos (vetoriais ou raster) e uma estrutura de armazenamento ambígua. Como faríamos?

Acho que deu para entender né?

Certo, eu te convenci? Ainda não? Certo. Então vamos levar a idéia para todo um contexto geotecnológico. Para o SIG/GIS.

Por que utilizar metadados junto com seus dados espaciais?

• Ajuda na organização (estruturada) dos dados;
• Evita duplicação de dados;
• Usuários podem localizar se determinado dado existe, para determinada região. De forma rápida.
• Auxilia e promove procedimentos gerenciais sobre os dados.

Em minha opinião, a parte mais importante do uso dos metadados é ter conhecimento do existe disponível, da qualidade, da escala apropriada, da data de levantamento. Os metadados permitem à você usuário determinar se algo serve para você ou não. Evita perda de tempo e claro, tempo é $$$.

Além disso, os metadados agregam valor aos seus dados geográficos. Ele pode ser procurado, encontrado e quem sabé até comprado por alguém?

Agora vamos tentar nos aprofundar um cadinho nos metadados. Existem basicamente três tipos de metadados, a citar: Discovery Metadata, Exploration Metadata e Exploitation Metadata. (isso de acordo com o pessoal do FGDC - visitem o site, tem muita coisa legal, inclusive dois livrinhos interessantes, um sobre metadata e o outro sobre Spatial Data Infrastructure)

Discovery Metadata: este tipo de metadata é o mais básico, e vai lhe dizer o que existe em determinada região e em qual dataset procurar. É nesta seção dos metadados que perguntamos as famosas:

• O que?
• Por que?
• Quando?
• Quem?
• Onde?
• Como?

Uma dica: este tipo de metadados é muito útil para se descrever uma coleção de dados. Uma série de mapas (humn, alguém já pensou em metadata para mapas ou coleções de mapas? Daniel S., lembra da idéia que te falei outro dia?)

Exploration Metadata: este tipo de metadado já um pouco mais complexo e lhe diz quais são as informações que cada dataset armazena, como as armazena. Este tipo ou nível é importante, pois lhe diz se o tipo de dados contidos em um tema podem contribuir com suas análises.

Exemplo: você quer realizar uma análise de rede em uma bacia hidrográfica. Mas e se o dataset for de polígonos?

Com o uso dos metadados exploratórios podemos assumir algumas proposições, especialmente se algum dado é adequado ou não para determinado propósito. Aqui conseguimos detalhes, informações armazenadas, tipo de armazenamento, formato, etc.

Exploitation Metadata: ah, este aqui é especial. Embora não seja diretamente relacionado com o uso imeadiato de um conjunto de dados, ele é crucial. Este tipo de metadados irá lhe dizer como os dados foram obtidos, à quais propósitos podem servir, limitações (técnicas, éticas, comerciais, judiciais), entre outros.

Este tipo de metadados também, é crucial: ele nos diz como acessar, transferir, carregar, interpretar, e utilizar os dados pelo usuário final. Seja para fazer mapas, seja para realizar cálculos complexos de um índice doido por aí. Aqui incluímos detalhes do dicionário de dados, organização dos dados, projeção, características geométricas, entre outros.

Se algum de vocês já olhou o esquema de metadados existente no ArcGIS (ele está conforme ao padrão do FGDC), pode notar que existem informações que as vezes se repetem. Sim, existe um certo nível de sobreposição entre os três tipos de metadados citados acima, mas cada um deve estudar e ver até onde é benéfico o preenchimento destes dados. Além disso, os tipos de metadados são complementares. Ou seja, quanto mais informações você tiver sobre os seus dados, melhor poderá organizá-los, achá-los mais rapidamente e utilizá-los de forma adequada.

Conforme prometi, esta seria uma introdução com comentários aleatórios sobre metadados. Por hoje é só. Mas prometo que voltaremos nesta discussão, por dois motivos: ela não só é interessante, como é extremamente necessária. Como de praxe, uma perguntinha: quantos de vocês utilizam diariamente os metadados? Seja procurando (sabia que o ArcCatalog tem uma caixinha de busca, e ela olha os metadados de cada arquivinho shape/geodatabase que você possui?) dados ou seja preenchendo a fichinha padrão dos metadados?

Um abraço

George

O corpo de conhecimento das Geotecnologias e a Geografia. Qual o real significado de uma para a outra?

Buenas noches a todos!

E aí pessoal, como anda a vida? Bem estou em São Paulo e estava lendo um post da lista de discussão da OSGeo. O post estava falando sobre o estabelecimento de um currículo "padrão" para cursos de Geographic Information Science e relacionados. Um equivalente no Brasil seria o curso de técnologo em Geoprocessamento, oferecido por alguns CEFETs (GO, PB, etc).

Bem, o post no final das contas, apontava dois links. Um para a certificação GISP (GIS Professional) e o outro se referia à um livro, editado pela AAG (Association of American Geographers), contendo as bases de formação para um profissional/pesquisador da área.

Bem, um sumário do livro pode ser encontrado aqui. O livro cobre uma diversidade de questões sobre o ensino e pesquisa em Geotecnologias. Eu até pedi uma cópia, por módicas U$25,00 doletas. Deve chegar em um mês.

Mas o mais interessante disso tudo, é um PDFzinho que fizeram, como um "apanhado" geral, de tudo relatado no livro.

Vejam a quantidade de coisas no sumário. Para quem está com preguiça de ver o PDF, vou listar aqui somente os principais tópicos listados:

• Analytical Methods

• Academic and analytical origins
• Query Operations and Query Languages
• Geometric Measures
• Basic Analytical Operations
• Basic Analytical Methods
• Analysis of Surfaces
• Spatial Statistics
• Geostatistics
• Spatial regression and econometrics
• Data Mining
• Network Analysis
• Optimization and location-allocation modeling
• Cartography and Visualization
• History and trends
• Data considerations
• Principles of map design
• Graphic representation techniques
• Map production
• Map use and evaluation
  
• Design Aspects
• The scope of GIS&T system design
• Project definition
• Resource Planning
• Database design
• Analysis Design
• Application Design
• System implementation
• Conceptual Foundations
• Philosofical Foundations
• Cognitive and social foundations
  
• Domains of Geographic Information
• Elements of Geographic Information
• Relationships
• Imperfections in Geographic Information
• Data Modelling
• Basic storage and retrieval structures
• Database management systems
• Tesselation Data Models
• Vector and object data models
• Modeling 3d, uncertain and temporal phenomena
• Data Manipulation
• Representation Transformation
• Generalization and Aggregation
• Transactional Management
• GIS&T and Society
• Legal aspects
• Economic aspects
• Use of geospatial information in the public sector
• Geospatial information as property
• Dissemination of geospatial information
• Ethical aspects
• Critical GIS
• Geocomputation
• Emergece of geocomputation
• Computacional aspects and neurocomputing
• Cellular automata
• Heuristics
• Genetic algorithms
• Agent-based models
• Simulation modeling
• Uncertainty
• Fuzzy sets
• Geospatial Data
• Earth geometry
• Land partitioning systems
• Georeferencig systems
• Datums
• Map projections
• Data qualitiy
• Land surveying and GNSS
• Digitizing
• Field data collection
• Aerial Imaging and Photogrammetry
• Satellite and shipboard remote sensing
• Metadata, standarts and infrastructures
• Organizational & Institutional Aspects
• Origins of GIS&T
• Managing the GI system operations and infrastructure
• GIST&T workforce themes
• Institutional and inter-institutional aspects

UFA! Quanta coisa. Cada tópico destes contém um ou mais subtópicos. Vocês podem imaginar que um profissional na área de Geotecnologias consiga dominar (de forma razoável) 90% desta lista?

Existem coisas nesta lista que a maioria de nós, nunca ouviu e talvez nunca nem ouvirá falar. Simulações e Cellular-Automata pode ser uma delas. Bem, como podemos ver é um currículo bastante extenso e completo.

Agora, fica a pergunta: qual é a instituição de ensino, no Brasil, que consegue mostrar a seus alunos, todo este conteúdo? A Geografia, consegue, em partes (muito pequenas) falar de modelos, simulação, análise espacial, entre outros. Peca em diversos outros temas. As faculdades de agrimensura tocam na superfície da maior parte destes assuntos, e priorizam outros. A engenharia cartográfica pode ser a mais completa delas, mas também duvido que consiga, de forma consistente, aplicar toda este rol de matérias, mas peca também, em alguns tópicos sobre análises.

Dos 10 tópicos principais, quais vocês acreditam ser de maior importância ao profissional de Geotecnologias? Se alguém, dizer que domina nove destes assuntos, por favor, me mande seu currículo Latters (no email mesmo) e me conte, por favor, como você fez um pacto com o outro lado.

Agora, para os geógrafos: deêm uma olhada no site da AAG. Deêm uma passeada. Olhem os sumários dos journals e periódicos. Agora entre neste site. Por que temos aqui no Brasil, uma associação tão fraca e que privilegia tão pouco as Geotecnologias?

Só de prestar atenção ao site da AAG, podemos notar que eles realmente conseguem trabalhar com uma única Geografia. Ao meu ver, não existe preconceito da parte dos geógrafos "humanos" com o trabalho da geografia física (no Brasil)?

Logo de cara, quem faz Geografia Física já não seria um positivista, e portanto, um "vendido" por tabela? Somente a Geografia Crítica, a Geografia Marxista e a Geografia do Strogonoff têm seu lugar ao sol? Será que a matemática, a estatística, a análise espacial e as geotecnologias, estejam assim, tão erradas?

Em um momento de muita discussão sobre o lugar da Geografia Física no Brasil, o que podemos tirar deste exemplo?

Só para lembrar: quem fez este currículo (citado acima) não foram os cientistas da computação, nem os "nerds" do sistemas de informação. Foram geógrafos. 

Agora, uma proposta minha: vou tentar pegar um assunto listado acima, e aprofundá-lo. Seja análise espacial, seja modelagem de dados, seja geocomputação. Vou escolher (vocês tem liberdade para escolher, opinar e me mandar...catar coquinho) e tentar destrinchar algumas coisas sobre um tópico em específico. Se fizer sucesso, tentaremos outro e assim por diante.

Um último pedido: se formos discutir geografia, fiquem à vontade. Discussão é saudável e faz bem. Irracionalidade, ofensas pessoais e outras coisas de desinteresse público não são necessárias. Explique seu ponto de vista e assim que possível, continuaremos o debate.

Um abraço,

George

Palestra PgCon BR 2009

O uso do PostgreSQL e PostGIS no cadastro geocodificado de acidentes de trânsito

View more presentations from georger.silva.

Rumos profissionais e Geoprocessamento

Boa noite pessoALL,

Como estão?

Hoje o assunto não é tecnologia. É profissão, carreira, essas coisas de Revista Você S/A.

Conheço muita gente que trabalha e trabalhou com Geoprocessamento. Não tenho muito tempo de profissão, sou um geógrafo recém formado, mas conheço bastante gente que trabalha com Geoprocessamento e seus diferentes estilos de trabalho.

Vamos analisar um caso hipotético de dois personagens, dois profissionais. Imaginem por um momento que tenham a mesma formação, a mesma disponibilidade de informação, etc. Se os dois fossem começar a trabalhar hoje, seriam iguais. Ah, vamos imaginar também que os dois profissionais são pessoas normais, têm família, estudam o que podem, quando podem e o que lhes é mais interessante.

Vamos dizer que o Sabilson, é um profissional com 10 anos de experiência com Geoprocessamento, aplicado à exploração mineral, ou utilities, ou transportes (ou qualquer área em que o Geoprocessamento possa ser aplicado).

Sabilson sabe tudo de transportes. Sabe todas as etapas de seu trabalho, conhece o modelo de dados (mesmo que em nível sub-consciente), todos os atalhos e "manhas", sabe como a coisa funciona dentro de sua organização. Ele conhece o organograma, as necessidades e as dificuldades. Sabilson é focado em transportes.

Se Sabilson mudar de emprego, e for trabalhar com Geomarketing, ele será tão bem sucedido quanto na área de transportes?

Será que Sabilson tem, depois de 10 anos de trabalho, a mesma disposição para um back to basics? Disposição de aprender banco de dados à fundo, ou programação, ou sobre Geomarketing aplicado?

Agora imagine o José. O José é um profissional que tem 10 anos de experiência, mas aplicado à diversas áreas. José conhece Geoprocessamento. José conhece um pouco de  programação orientada à objetos, conhece Análise espacial e conhece banco de dados geográficos. Conhece os fundamentos, os princípios e sabe o que é uma chave primária, um objeto, uma classe e tenta adaptar seu raciocínio à qualquer área ou projeto que trabalhe.

Mesmo que tenha dificuldades em conhecer o emaranhado de detalhes existente em determinada área, como transportes por exemplo (que geralmente possui um modelo de dados complexo, cheio de tabelas, muita informação temporal), ele conseguirá aprender e dominará com certa rapidez as necessidades existentes?

Existem áreas que são delicadas demais para José? Será que ao invés de José, o projeto não precisasse de um Sabilson? Um profundo conhecedor de um determinado ramo?

Sabilson leva vantagem sobre José em algumas coisas: sabe o que funciona e o que não funciona. Mas José tem à seu lado ferramentas indisponíveis (em teoria) para Sabilson, e pode desenvolver meios de trabalhar de forma mais rápida.

Agora as perguntas. Gostaria de ouvir (ou ler :P) comentários sobre isto.

Qual dos dois profissionais têm, à longo prazo, mais chance de sucesso? Qual deles é melhor valorizado? Qual deles tem maior prestígio?

Tenho certeza que temos lugar no mercado para os dois tipos de profissionais, são estilos difererentes. Qual é o seu estilo?

Durante o tempo que trabalho com Geotecnologias, vejo estas duas tendências nos profissionais da área. O generalista ou o específico. Vocês percebem esta diferença? Ela existe ou estou viajando na maionese?

Existe alguma formação que privilegia um estilo de trabalho? Alguma formação é mais indicada para cada tipo?

PS: não existe um perfil "certo". Cada um tem o seu, e faz o melhor com que se tem a disposição.
Abraços

PgCon BR 2009 - Campinas

Opa pessoal! Vamos fazer um pouco de propaganda aí!

Nos dias 23 e 24 de outubro, ocorrerá em Campinas a PgCon BR!

Serão diversas palestras de grandes programadores, DBAs e usuários sobre o maior (e melhor, sorry MySQL) banco de dados livre do mundo.

As palestras são diversas, com temas importantes para os utilizadores deste grande software, desde otimização do banco de dados, desenvolvimento de extensões, e claro, PostGIS.

São duas palestras sobre a extensão espacial, uma delas, ministrada por mim, sobre o uso do PostgreSQL + PostGIS para o cadastro de acidentes de trânsito.

Grandes nomes internacionais estarão no evento, como Bruce Monjiam e Magnus Hagander. Vale a pena ir e conferir as palestras.


A programação está disponível em: http://pgcon.postgresql.org.br/2009/programacao.php

Ah, faça sua inscrição antes do dia 13. Tem desconto!



Vamos participar e ajudar este software maravilhoso à crescer!

Análise espacial: rapidinha 2

Quanto à pergunta que fiz no post anterior: como o ArcGIS trabalha com áreas de análise irregulares (não ímpares e de altura largura diferentes?)

Bem, imagine a seguinte área de análise (definida em qualquer ferramenta de matemática de rasters/estatística de rasters - na análise focal)

-----------------
2 3
1 1 1
1 1 1
-----------------

Qual é a célula central deste bloco? O ArcGIS trunca o bloco, permitindo selecionar a célula a ser reescrita.

No caso acima, ele analisa duas linhas com três pixels cada. A célula central de cada linha é a célula de número 2 (1 2 3). Mas qual é a célula central na altura? O software considera ela sendo a célula de número 2, na linha 1, para este bloco especifico.

No caso proposto acima, somente esta célula seria reescrita.

Análise Espacial: tipos de análise

Boa noite pessoal,

Hoje vou passar para deixar uma rapidinha.

Muita gente fala sobre análise espacial, matemática de rasters, mas as vezes esquece de alguns conceitos importantes.

Existem três tipos de análise (numérica) que podemos fazer com um raster: Local, Focal e Block.

É importante entender a separação sobre estes tipos de análise, pois de posse deste entendimento podemos utilizar a ferramenta correta, para a situação correta.

Vamos lá.

Local Analysis (análises locais): as análises locais ocorrem célula por célula, sem levar em conta as vizinhas. Um exemplo de análise local é a divisão de um raster por outro. Ou qualquer conta matemática que possamos imaginar para determinado pixel ou célula. As expressões condicionais, e outras se aplicam aqui. Não só aqui, mas principalmente. A chave aqui é célula por célula, quadradinho por quadradinho

Focal Analysis: as análises focais levam em conta seus vizinhos! Mas alteram célula por célula! Vamos complicar: imagine que temos um modelo digital de terreno, SRTM, e queremos que ele fique, digamos, mais redondinho. Podemos utilizar para isto a ferramenta (ArcGIS pessoal) Focal Statistics.

O que esta ferramenta faz é criar um bloco imaginário (com o formato escolhido pelo usuário - círculo, retângulo, annulus (donut), triângulo ou kernel (já já explico o que é o kernel)) conforme especificado, e analisar as células bloco à bloco, e retornando o resultado para a célula CENTRAL. Este bloco imaginário é também chamado de janela, ou window. Após a análise das células contidas nesta janela, a janela se desloca em um pixel (em geral da esquerda para direita) e realiza a análise novamente. Autores chamam estas técnicas de moving window - deu para entender o porque né? Conseguem imaginar um quadradinho de contendo n pixels parando em uma posição (um subset da imagem completa), fazendo as contas, e andando?

As janelas, obviamente, devem ter tamanhos maiores que 1x1 px. Se a janela é do tamanho de 1 pixel, ela deixa de ser uma análise focal!

No mesmo caso das análises locais, diversas equações podem ser explicitadas, e o software que se vira para realizar todas elas. Nota importante: no ArcGIS, as operações especificadas nas operações com raster NÃO SEGUEM REGRAS DE PRECEDÊNCIA (multiplicação sempre deve ser realizada antes da soma ou subtração, por exemplo), ou seja, são avaliadas como escritas, da esquerda para direita. Caso você precise de aplicar regras de precedência, utilize ().

Block Analysis: as análises em bloco são MUITO úteis para se generalizar informação. Elas funcionam da mesma maneira que as análises focais, mas ao contrário de assinalar o resultado à célula central, assinalam o resultado para o bloco inteiro. Não tem mistério. edit: as análises em bloco se movem, assim como as focais, mas se movem de bloco em bloco, não de pixel em pixel.

O que é o tal do kernel? Bem o ArcGIS, permite aos usuário uma grande flexibilidade para criação de formas complexas para análises espaciais. Ele é simplesmente um arquivo texto puro, contendo uma indicação do que deve ser considerado como bloco. Ex:

-----------------------------

3 3

0 1 0

1 0 1

0 1 0

-----------------------------

A primeira linha, sempre especifica o número de linhas e colunas do arquivo. No nosso caso acima, 3x3.

Valores = 0 -> Não serão inclusos na análise (terão peso ZERO).

Valores = 1 -> Peso 1, incluídos na análise.

Outros valores numéricos: se especificarmos que o kernel têm peso (WEIGHTED KERNEL), outros valores, como 2 ou 3, serão aplicados como pesos nas análises.

Os arquivos kernel permitem análises com formas irregulares, facilitando a modelagem de alguns fenômenos.

Existem outras considerações à serem feitas sobre este assunto, mas no momento não veem ao caso, como por exemplo: Se meu bloco (aplicado em análise focal) é irregular, qual é a célula central?

Imagine um retângulo 2x3. Qual é a célula central? Alguém tem um palpite?

Abraços pessoal.

Piauí

Pessoal,

Estou no Piauí. Não, não morri. As atualizações ficam pra depois, pois o trabalho está matando!

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:

ID

X

Y

Z

Sistema_coordenada

Sempre com diversos pontos e diversos sistemas de coordenadas "misturados". Até aí tudo bem.

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

1. Sempre olhe no Codeplex.
2. Para registrar uma dll externa (dentro do Sql Server) utilize (isto é código SQL): CREATE ASSEMBLY ProjNet 'caminhoParaDll'
3. Para registrar uma função: CREATE FUNCTION nomeFuncao (parametros) returns tipoRetorno AS external ProjNet.Namespace.Funcao
4. É 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.

Geoprocessamento e acidentes de trânsito

Olá novamente pessoal,

Venho falar com vocês de um assunto sério: acidentes de trânsito. Matam milhares de pessoas, ferem outras milhares e custam aos cofres públicos milhares de reais anualmente. Claro que o dinheiro neste caso não é o denominador comum, mas imaginem:

De acordo com o IPEA (Instituto de Pesquisas Econômicas Aplicadas) cada acidente de trânsito custa, em média, por vítima envolvida:

• vítima ilesa: R$1.040,00
• vítima ferida: R$36.305,00
• vítima fatal: R$270.165,00

São valores absurdos. Isso, de acordo com o IPEA, envolve não só custos materiais e despesas hospitalares, mas também perda de produção, ou seja, dias parados no trabalho.

Bem, e o que Geoprocessamento ou SIG tem à ver com isso? Bem, um acidente é um evento extremamente complexo, com diversas variáveis importantes para uma macro-análise do trânsito e da segurança viária. Então, como conhecer um acidente de trânsito e suas variáveis? Como analisar a frequência de acidentes e as condições de tráfego de cada via? Podemos correlacionar os acidentes com mau tempo?

Um sistema que cadastre e analise acidentes é o ideal. Mas como localizar cada acidente? Temos à nossa disposição em quase todos os softwares de SIG/GIS ferramentas que executam a geocodificação. A geocodificação é basicamente o processo de se assinalar uma localização pontual (um ponto) à uma descrição textual, geralmente um endereço. Podemos utilizar ferramentas de geocodificação para localizar acidentes? Afirmativo. E focos de dengue? Afirmativo. E...qualquer coisa que possua um endereço em seu cadastro.

Um sistema deste tipo pode ajudar a salvar vidas e a diminuir o gasto público com obras ou medidas de segurança desnecessárias. Um sistema que realize este trabalho pode dar aos responsáveis pelo planejamento viário, subsídio técnico-científico para a proposição de medidas concretas.

Durante minha monografia, tentei desenvolver um sistema que fizesse este tipo de trabalho. Utilizei para o trabalho o banco de dados PostgreSQL e PostGIS e um algoritmo de geocodificação desenvolvido por David Bitner (não tenho o endereço do algoritmo, mas se quiserem dar uma olhada só me pedir por email). Funcionou?

Funcionou, mas existem alguns percalços no caminho: a polícia militar e outros órgãos que registram os acidentes de trânsito em boletins de ocorrência, algumas vezes registram somente a via em que o acidente ocorreu e as vias que interseccionam aquele trecho (Rua X, entre rua A e Avenida B) ou somente o cruzamento em que o mesmo ocorreu. Ferramentas de geocodificação tradicionais não suportam este tipo de endereçamento, portanto utilizei um pouquinho de código pl/pgsql para adicionar esta funcionalidade. Seria um sistema muito ruim se mais da metade dos acidentes cadastrados não fossem possíveis de serem geocodificados. Qualquer análise espacial realizada seria furada, pois os dados não estão completos.

Certo, mas o que eu preciso para montar algo similar? Ok, vamos lá.

1. Uma base de referência de logradouros, com os seguintes atributos (ou similares): ID_Trecho, ID_Logradouro, Tipo_Logradouro, Nome_Logradouro, Numero_Inicial_Esquerdo, Numero_Inicial_Direito, Numero_Final_Esquerdo e Numero_Final_Direito, Intersecao_Anterior e Intersecao_Posterior. A base deve conter os trechos de logradouros devidamente preenchidos. Você pode usar um Guia Sei ou IR A CAMPO, e anotar estas numerações. Claro que para um projeto maior isto não funcionaria, mas é um começo. Nos campos Numeracao*, devem constar as numerações iniciais/finais de cada lado da via e em Intersecao* os logradouros que interseccionam aquele trecho.
2. O algortimo geocodificador e um serviço geocodificador. Tudo isto vem com o algoritmo. O algoritmo é um pedaço de código que é orientado pelo serviço. O serviço é criado preenchendo-se a tabela correta, onde indicaremos qual é a base de referência e quais são os campos de interesse.
3. Não tem três. É só isso.

 Bem cada acidente tem suas características, um número x de veículos envolvidos e outras informações relativas à cada motorista e gravidade de ferimentos (por veículo). A maioria dos algoritmos geocodificadores possuem ferramentas para geocodificação ad-hoc (propósito em si) e podemos desenvolver maneiras para geocodificador dados em batch (ou fornadas, levas, etc.).

No caso deste trabalho, foi desenvolvido um trigger ou gatilho, disparado assim que um usuário inserir alguma coisa na tabela que registra os acidentes, realizando uma busca pela representação pontual daquele endereço. Este trigger também avalia o tipo de endereço inserido pelo usuário, se ele representava um endereço completo (Rua A, 768) ou se representava um cruzamento (Rua A com Rua B) ou se apenas continha os valores das interseções (Rua A, entre Rua B e Rua C).

As funções complementares, que geocodificam entre intersecções ou em cruzamentos são apenas o uso simples de SQLs comuns e da função nativa do PostGIS ST_Line_Interpolate_Point, que recebe como argumentos a linha que se deseja interpolar a uma porcentagem.

Certo, como localizar um cruzamento? Bem, lembra que nossa base de referência possui o atributo Sufixo_Direcao e que este representa para qual linha "estamos indo"? Então, para selecionar a linha e mandar ela para a função, foi utilizando o seguinte:

SELECT * FROM logradouros WHERE Tipo_Logradouro = 'TipoEscolhido AND Nome_Logradouro = 'NomeEscolhido' AND Sufixo_Direcao = 'IntersecaoPosteriorEscolhida'.

 

À partir daí é só o caso de jogar na função: ST_Line_Interpolate_Point(ResultadoQuery,.99). A função já lhe retorna o ponto desejado.

E como usar esta função para localizar um acidente que ocorreu entre intersecções? Bem, como não temos idéia de onde o acidente ocorreu na via, utilizamos o ponto médio do logradouro para localizá-lo. A função utilizada é a mesma, a única coisa que muda é o SQL, onde especificamos também um Prefixo_Direcao e ao invés de .99 na porcetagem da função, utilizamos .5, nos retornando o exato ponto médio daquele trecho.

Bem isso foi apenas uma pequena introdução à geocodificação e ao pequeno trabalho que realizei durante o ano de 2008. O sistema está pronto e funcioona! Mas ninguém usa :P. Já existe um sistema para cadastro de acidentes em Uberlândia, mas é um sistema proprietário, e quem o desenvolvou não tem nem idéia do que Geoprocessamento significa. Ainda vai levar um bom tempo para os órgãos públicos descobrirem o tanto que as novas tecnologias podem ajudar, a poupar e neste caso, até a salvar vidas.

George

#Python: parte 2 e 1/2

Bom dia pessoal,

No post #python parte 2, eu deixei como exercício para vocês uma pequena tarefa. Como podemos perguntar ao usuário qual é pasta que ele quer projetar e qual a projeção. Existem duas maneiras, uma delas é criar o script para rodar somente dentro do ArcGIS ou utilizar algum tipo de manipulação dentro do script, que roda em DOS/Python.
Vou mostrar a segunda maneira. Os scripts criados pelo ArcGIS são bastante simples, mas é preciso um pouco mais de base teórica, então fica pra depois.

Bem, para isso precisamos utilizar umas manhazinhas. Esta solução vai em duas partes, e poderia ser muito mais complexa, mas o Python vai nos ajudar.

Primeiramente, como perguntar qualquer coisa ao usuário? O Python tem uma pequena função chamada raw_input.

A função raw_input tem como único argumento opcional uma mensagem à ser passada ao seu usuário, mostrando a ele o que ele tem de digitar:

pasta = raw_input("Digite a pasta onde se encontram os shapefiles. ")
#funciona
pasta2 = raw_input()
#funciona também, mas sem mensagem

Bem, antes do script rodar e começar a tentar processar as pastas, é bom testar se o valor que o usuário digitou é válido. Existem diversas validações que poderiam ser executadas, mas vamos usar uma em especial.

#lembre-se que cada - equivale à um espaço e um conjunto com ---- equivale à uma tabulacao.

import sys, os, arcgisscripting

pasta = raw_input("Digite a pasta que deseja projetar. Lembre-se de duplicar as barras \\ senão não acho o caminho. ")

if os.path.isdir(pasta) == true:
----#é uma pasta válida e existe.
----#processe
else:
----#não é uma pasta válida.
----#imprima uma mensagem de erro e saia do script.
----print "Erro, a pasta indicada não é válida."
----exit

Bem pessoal, esse é o começo de tudo. Não repetirei os processamentos com o arcgisscripting, e isso é pra vocês estudarem e tentarem por aí.

Não se esqueçam, o F1 do Python traz a ajuda da versão utilizada, que contém as assinaturas de funções (quais são os paramêtros de entrada e qual é a saída), notas importantes e exemplos de como usá-las.

Agora, como permitir o usuário escolher o datum? Essa é um pouco mais difícil. Teremos de usar um outro tipo de dados do Python, chamado dicionário, que é tão poderoso quanto as listas, mas existem algumas diferenças sobre ele. O dicionário não suporta aquela maravilha de "for x in lista:", pois ele é um...dicionário, e não uma lista.

Os dicionários tem alguns métodos que nos ajudam a achar o que queremos:

a = {'SAD6922SUL':'\\Coordinate Systems\\Projected Coordinate Systems\\Utm\\Other GCS\\South American 1969 UTM Zone 22S.prj'}

Este é um dicionário com somente uma entrada. Enquanto as listas utilizam a posição de cada item (de 0 à n), os dicionários utlizam as keys. No caso supracitado, a key para este endereço monstro é SAD6922SUL, ou seja, ela armazena um valor, que é o diretório para este datum.

Métodos:
len(dicionario) retorna o tamanho do dicionario.
k in dicionario. Verdadeiro se a chave k está presente no dicionario dicionario.
k not in dicionario. Verdadeiro se a chave k NÃO está presente em dicionario.
dicionario.has_key(k). Mesmo que k in dicionario. Versão nova da função.
dicionario.keys(). Copia as keys para uma lista.
dicionario.values(). Copia os valores para uma lista.
dicionario[k] = v. Adiciona uma chave k com o valor de v no dicionario.

Existem outros métodos, mas estes são os mais básicos e necessários para começar.

Imagine o seguinte dicionario:

dicionarioDatums = {'sad69utm22s':\\Coordinate Systems\\Projected Coordinate Systems\\Utm\\Other GCS\\South American 1969 UTM Zone 22S.prj',
'sad69utm23s':'\\Coordinate Systems\\Projected Coordinate Systems\\Utm\\Other GCS\\South American 1969 UTM Zone 23S.prj',
'sad69utm24s':'\\Coordinate Systems\\Projected Coordinate Systems\\Utm\\Other GCS\\South American 1969 UTM Zone 24S.prj'}

e o código a seguir:

chaveDatums = dicionarioDatums.keys()

for chave in chaveDatums:
----print chave

datumEscolhido = raw_input("Digite o datum de sua escolha. ")

if datumDicionario.has_key(datumEscolhido):
----#processo
else:
----print "Você não escolheu um datum válido. Reinicie e tente novamente."

Bem, veja que hoje apenas estruturei a solução. Quero ver algum código aí nos comentários. Alguém tem uma outra idéia para fazer isso?

É bom notar que existem melhoras a serem feitas neste script, por exemplo, forçar o usuário a digitar algo correto no último raw_input, e software não sair daí enquanto ele não o fizer. Existe também a possibilidade de se mapear a pasta Coordinate System automaticamente, sem a necessidade de sempre que precisarmos de um datum novo, que não está na lista, reescrever o código. Deem suas sugestões e espero ter ajudado.

Abraço

George