Metadados 3: Padrões de Metadados

Buenas noches compadres e comadres.

Bem, vamos à terceira parte do nosso post sobre metadados. Os padrões, ou standards.

Primeiramente, por que usá-los?

• São padrões. Todo mundo o mesmo estilo de metadados. Isso se traduz em facilidade para ler/editar diferentes fontes.
• Os padrões foram elaborados por experts. Gente que entende do assunto, com muitos anos de experiência na área. Não estou dizendo que você ou outras pessoas não tem conhecimento para acrescentar ou mudar uma coisa ou outra, estou dizendo que só deve fazer isso quando extremamente necessário.

Os dois motivos acima, em minha opinião, já são suficientes para se adotar um, dos muitos padrões (e sub-padrões) existentes.

Atualmente, bem difundidos e utilizados, inclusive com suporte de software, existem três tipos de metadados (sem contar o ESRI FDGC, aquilo lá é uma modificação do FDGC atual).

1. Content Standard for Digital Geospatial Metadata
2. CEN Pre-Standard
3. ISO 19115/19139

1 - Content Standard for Digital Geospatial Metadata

Este padrão foi desenvolvido pelo FDGC, em 1994. Este padrão de metadados foi desenvolvido para suportar a infraestrutura nacional de dados espaciais norte-americanos (em 1994...humn, 14 anos na nossa frente!)

Existem diversos países que utilizam este padrão, incluindo Canadá, África do Sul e Reino Unido. Fiquem atentos para os "plugins" de padrões. Existem padrões de metadados desenvolvidos pelo FDGC que cuidam de wetlands, geology, biology entre outros tipos de metadados.

2 - CEN Pre-Standard

Este padrão foi desenvolvido na Europa desde 1992 e foi adotado em 1998. É fruto de cooperação internacional.

3 - ISO 19115/19139

Ah...o padrão ISO. Este padrão foi aprovado em 2003 e como o modelo europeu recebeu inputs de diversos órgãos ao redor do mundo. Na verdade, uma massaroca de padrões utilizados ao redor do mundo foram utilizados como entrada e no final, a ISO separou o joio do trigo.

A ISO 19115 dá um modelo abstrato para organização dos metadados (de dados espaciais), sem implementar ou forçar um modelo rígido.

Já a ISO 19139 especifica e pontua claramente como implementar os metadados utilizando XML e inclui o modelo lógico da 19115. São dois documentos importantes para leitura/consulta.

4 - Padrão OGC (ahá, mais um padrão!)

A OGC (Open Geospatial Consortium), órgão monstro em tudo que se trata de SIG/GIS e afins tem seu perfil de metadados! Só o nome que não tem metadados no meio, mas é metadados. O padrão se chama Catalogue Service e já está na versão 2.x. Os documentos, para os interessados, está no site:

http://www.opengeospatial.org/standards/cat

Certo, o que aprendemos hoje?

• Existem diversos padrões de metadados e não iremos reiventar a roda.
• Padrões são legais. Não vão te deixar (muito) doido. É melhor utilizar um existente, para conformidade de bases, facilidade de leitura/escrita.
• Que eu não falei do padrão brasileiro de metadados.

Pessoal, me desculpem pela demora. Mas a coisa anda corrida. Assim que tiver um tempinho, irei falar sobre o padrão brasileiro. Um capítulozinho nesta saga só para ele.

Como sempre, aceito sugestões, críticas e uns trocados. Um feliz natal atrasado e um feliz ano-novo cheio de dados espaciais (ainda não consigo sortear entradas para eventos e dar livros de presente...).

Um abraço

Novos desafios, denovo!

Boa noite pessoal,

Venho trazendo algumas notícias e pedir para vocês não me esquecerem!

Consegui um outro emprego, este na área de TI e desenvolvimento para GIS, numa excelente empresa. Irei trabalhar por mais alguns dias aqui em São Paulo e logo logo devo ir para a casa do projeto, Belo Horizonte.

Belohorizontinos, até logo.

Não esqueci sobre o post dos padrões de metadados. Prometo que esta semana posto ele.

Um abraço

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

#Python, parte 3

Boa noite pessoal,

Como disse anteriormente o Python é a linguagem "preferida" pela ESRI para se construir ferramentas e modelos de geoprocessamento.

Na última vez, usei um exemplo pequeno, mas até útil.

Hoje vou mostrar como se pode fazer múltiplas operações, com uma só Feature Class.

O Python é ótimo em executar tarefas tediosas e repetitivas, daquelas que gastaríamos anos para terminar se feito na mão.

Imagine que você precise converter uma série de SRTMs para pontos, juntá-los, e depois interpolar tudo isso (espero que seu computador seja bom :P)

Vamos ao exemplo:

#lembrem-se que o python faz questão de código identado, se ele não tiver identado, não funcionará.
#aqui ao invez de espaços usaremos -

#vamos importar nossas coisas
import sys, os, arcgisscripting, string

gp = arcgisscripting.create(9.3)

diretorio = raw_input("Digite o diretório que contém os rasters. Não se esqueça de duplicar as barras \\, senão não conseguirei achar o caminho...")
#aqui você pode indicar qualquer coisa, um diretório, um banco de dados SDE e até um banco de dados file/personal.
if diretorio:
----pass
else:
----print "Workspace/Espaço de trabalho inválido. Reinicie o script e tente denovo."
----exit()

gp.Workspace = diretorio

ListaRasters = gp.ListDatasets("*","Raster")
#se tivessemos escolhido "SRTM*" ao invés de "*" o Python listaria todos os rasters que começam com as letras SRTM

gp.AddToolbox("conversion") #adiciona a toolbox conversion
gp.AddToolbox("sa") #adiciona a toolbox do spatial analyst - só funciona para quem TEM a licença eim pessoal.
gp.AddToolbox("management") #adiciona management

#já temos nossas ferramentas, mãos à obra.

for Raster in ListaRasters:
----OutFeature = diretorio + "\\" + "ponto_convertido_" + Raster
----gp.RasterToPoint_conversion(Raster,OutFeature)
----print Raster + " convertido para ponto."

#vamos listar nossas feature classes de ponto. lembra do "*"?
ListaFeatureClasses = gp.ListFeatureClasses("ponto_convertido_*","POINT")
#assim garantimos que só vamos mosaicar as featureclasses convertidas e não outras perdidas no mesmo workspace, e claro só do tipo ponto :D

#a ferramenta merge exige uma lista das featureclasses a serem juntadas separadas por ponto e virgula, entao vamos dar a ela o que ela quer!

OutputMerge = gp.Workspace+"\\" + "MergeFinal"

gp.Merge_management(string.join(ListaFeatureClasses,";"),OutputMerge)
#a funcao join concatena uma lista utilizando um caractere (ou caracteres separadores) ou seja: ['shape1','shape2',shape3'] viram shape1;shape2;shape3

print "Já está tudo junto, vamos interpolar?"
print "interpolando. deve demorar, vá tomar um café..."

gp.Idw_sa(OutputMerge,"VALUE",gp.workspace+"\\"+"raster_interpolado",30,1)

print "interpolado. parabens!"

Bem pessoal, não testei o código, mas deve funcionar de acordo. O python é muito poderoso e suas funções internas se encaixam muito bem com a API da ESRI. Vejam na parte do Merge. Em outras linguagens teriamos de escrever loops e loops para concatenar as palavras daquela maneira, mas em python tudo é feito rapidinho!

Espero que gostem e que comecem a utilizar Python no seu dia a dia. É de fato um negócio muito útil. 1 hora para escrever um script, mas te salva 80mil horas de trabalho chato, cansativo e passível de erro humano.

Ahn! Não se esqueçam de consultar a documentação das funções utilizadas (join do Python, Merge_management, RasterToPoint_conversion e IDW_sa). Todas as versões do Help do ArcGIS possuem essa documentação. É só apertar F1 e correr para o help de cada ferramentinha, na última parte delas, Scripting. Se acharem algum erro no código postados, favor dar um toque que eu corrijo.

Python Rocks!

#Python parte 2 - utilizando objetos de geoprocessamento

Buenas pessoal,

Bem, Python, como expliquei no post passado é uma linguagem de alto nível e muito recomendada pela ESRI para se construir modelos de geoprocessamento (semelhantes aos construídos no ModelBuilder) e scripts para processamento de informações.

Primeiro, para quem deseja aprender Python:

python.org e python.org.br

Aqui encontramos algumas coisas fundamentais, como documentação e links para trocar idéias com a comunidade que desenvolve em Python.

Segundo: irc.freenode.net nos canais #python e #python-br . Nestes locais é possível conversar com desenvolvedores brasileiros e internacionais e resolver possíveis dúvidas.

Terceiro: este aplicado a quem quer integrar esta poderosa ferramenta aos seus métodos de trabalho - WebHelp ESRI e WebHelp Esri 2.

Não tenha medo de errar e não tenha medo de buscar ajuda.

Então vamos lá.

Para qualquer coisa que você queira fazer em python, é necessário importar o módulo que cuida dos objetos geográficos da ESRI, o arcgisscripting.

#importando o módulo arcgisscripting
import arcgisscripting

Quando um script .py contém esta instrução (ela deve ser feita no ínicio do seu script), o python deixa a sua disposição os objetos da ESRI. No webhelp você pode encontrar uma descrição ampla de TODOS eles, bem como exemplos.

Certo, mas depois que este módulo está disponível, o que fazemos para começar a mexer com o ArcGIS?

É necessário criar um objeto do tipo geoprocessing, fornecido pelo módulo arcgisscripting. Olhem o exemplo

gp = arcgisscripting.create()
#este método, sem parâmetros serve tanto para 9.2 quanto para 9.3
#para 9.3, é melhor especificar o paramêtro 9.3 e.g.: gp = arcgisscripting.create(9.3)

O que podemos fazer com o Python? Bem, em teoria, tudo o que estiver disponível dentro de uma Toolbox do ArctoolBox também está disponível para o Python. O Python na verdade, consegue fazer qualquer coisa que esteja em uma toolbox e ainda mais!

Lembre-se que o Python contém muitos módulos, como acesso à sítios remotos, módulos para gerenciar emails, matemáticos, FTP, conversores para PDF, acesso à banco de dados (MSSQL, PostgreSQL, SQLite, entre outros), manipuladores XML...ou seja, é muito flexível e extensível.

Para realizarmos operações dentro do ArcGIS, temos que utilizar o módulo sys e geralmente o módulo os, ambos nativos no Python. Hoje não falarei de como construir scripts que rodam à partir do ArcGIS, apenas scripts que rodam diretamente da shell python (alguém conhece alguma utilidade pra isso? acessar objetos geográficos sem abrir o ArcGIS?)

Bem, imaginemos que queremos Projetar ou Definir projeção de diversos itens, ao mesmo tempo:

#projetar diversos shapefiles para uma única projeção
import sys, os, arcgisscripting

Caminho = "C:\\Pasta\\Shapefiles\\"
#no Python, temos de duplicar as barras, pois uma barra \ é interpretada como alguns
#caracteres especiais, como nova linha, tabulação, entre outros

gp = arcgisscripting.create(9.3)

#vamos projetar shapefiles/featureclasses. temos de utilizar
#as toolboxes correspondentes, entao vamos adicioná-las

gp.AddToolbox("C:\\CaminhoAtéAToolbox\\Nome da Toolbox.tbx")

#podemos adicionar tantas toolboxes quanto precisarmos
#só devemos lembrar que mesmo através de scripts Python, as licensas de extensões
#SÃO CHECADAS. se você não tiver o spatial analyst, o Python irá dar um chilique

gp.Workspace = Caminho
#vamos definir o workspace. No ArcGIS + Python, muita coisa depende do workspace.
#ele é basicamente um apontamento para o diretório correto.

ListaShapefiles = gp.ListDatasets("*","ALL")
#vamos criar um objeto do tipo lista, e inserir nela todos os objetos do arcgis.
#os parametros "*" e "ALL" está dizendo para o ArcGIS inserir na lista todos
#os objetos, sem especificação de tipo (que podem ser Feature, TIN, Raster e CAD)

print ListaShapefiles
#me mostre o que será projetado

projecao = "C:\\CaminhoAteAProjecao\\Projecao.prj"

for Shapefile in ListaShapefiles:
----gp.Project_management(Shapefile,Shapefile+"_projetado",projecao)
----print "Projetei " + Shapefile

#considere os quatro - como uma identação, um toque na tecla tab (o blog está engolindo os espaços)
#fim

Este script é bem simples, deve ser salvo como .py, e ser rodado através da shell python ou com dois cliques no mesmo (desde que o Python esteja devidamente e corretamente instalado).

Algumas notas no entanto: note a forma que duplicamos as barras. Se você utilizar somente uma barra o Python não conseguirá achar os caminhos corretamente.

Os nomes de saída da função project são Shapefile_projetado.

A identação no trecho "gp.Project_management..." é PROPOSITAL E DEVE ESTAR LÁ. SEM ELA O SCRIPT NÃO FUNCIONARÁ. O Python usa a identação obrigatória como forma de controle de código.

Não se esqueça, tudo o que vem depois de # é considerado pelo Python um comentário, não influenciando no programa.

Note que para projetar uma pasta/set de shapefiles diferentes, temos que alterar a variável Caminho, lá em cima. O que podemos fazer para dinamizar esta questão? Como podemos perguntar ao usuário qual é a pasta que precisamos projetar? E a projeção, como definir ela dinamicamente? Essa fica de dever de casa :P

E agora senhores, o que podemos fazer com Python? Podemos utilizar todas as Toolboxes do ArcGIS para realizar milhares de operações com diversos shapes/featureclasses, e até mesmo cosntruir modelos complexos, do tipo que vemos em ModelBuilder, simulando eventos.

Vamos aprender Python?

#Python: o que é?

Olá pessoal,

Primeiro gostaria de falar sobre a Geo Rede. GeoRede é um projeto do site Geoprocessamento.net, um agregador de feeds de diversos blogs sobre Geoprocessamento/Sensoriamento Remoto em geral.

Estou lá também! Depois passem lá e deêm uma olhada. Se você não conhece o Geo.NET é mais uma coisa bacana. Fórum, seção de downloads e muito mais.

Bem, hoje falo para os usuários de ArcGIS. Vocês já devem ter notado, que durante a instalação do ArcGIS ele te pergunta/pede para instalar uma linguagem de programação chamada Python. Bem, se algum de vocês já abriram a aba dela no menu Iniciar do windows devem ter se deparado com algo bastante simples, a IDLE. A IDLE é um shell que intepreta comandos em Python. Algo como o DOS.

Bem, não dá pra fazer muita coisa pela IDLE, já que estamos limitados a "programas" de uma linha. Mas o porque estou falando de Python? O ArcGIS, felizmente, tem um ambiente customizável e permite ao usuário mais avançado a desenvolver suas próprias ferramentinhas, para executar uma infinidade de ações. Desde tarefas de "geoprocessamento" (geoprocessing) à customizar suas layers e representações.

Existem duas maneiras de se estender o ArcGIS. Uma delas é através de uma linguagem compilada .NET (ou VBA) e através do Python.

De acordo com a própria ESRI, a linguagem recomendada para se trabalhar com geoprocessing é Python. O .NET é mais fácil caso você precise estender a GUI (Graphic User Interface) e montar coisinhas mais complexas. O Python é recomendado para geoprocessing e a criação de ferramentas mais simples justamente pelo Python ser simples. A linguagem Python, criada em 1991, é considerada VHLL (Very High Level Language) e traz enormes facilidades para desenvolvedores iniciantes.

Primeiramente, ela é dinamicamente tipada (what the hell?!). Bem isso significa que não é necessário declarar com QUE tipos de variáveis queremos trabalhar antecipadamente. Você coloca alguma coisa na variável e o Python identifica o que ela é pra você. Ou seja, não existe muita confusão no momento de falar que A = 3 ou A = "spam". (neste exemplo, A = 3, representa automaticamente que A é uma variável do tipo inteiro e que em segundo momento, ela é do tipo string)

Segundamente, Python não é uma linguagem compilada. Não é necessário desenvolver um arquivo executável ou algo do tipo, ela é interpretada conforme o Python lê o código digitado. Isso traz uma perda de velocidade (nada muito importante) mas o ganho em agilidade no desenvolvimento compensa.

Python tem tipos muito flexíveis, como listas e dicionários. Não entrarei em detalhes, mas você pode com uma única expressão, criar uma lista com valores que você esteja trabalhando e de forma mais fácil ainda, ler os mesmos.

Um exemplo de lista, que sempre estão entre COLCHETES:

ListaTeste = ['spam','geoprocessamento',2,['arcigs','envi','arcsde']]

Temos na lista acima os items 'spam', 'geoprocessamento',2 e uma outra lista! aninhada, com os objetos 'arcgis','envi' e 'arcsde'. Listas são o carro-chefe do Python e devem ser aprendidas o quanto antes. Através delas podemos fazer o capeta com muito pouco código.

Agora, como integro ArcGIS com Python? A ESRI disponibiliza uma "API" própria para manipulação (de seus) objetos geográficos, como Feature Classes, Layers, Datasets, Geodatabases entres outros.

tudo o que tiver após # são considerados comentários, e não são interpretados pelo Python.

Um exemplinho simples de um script em Python (embora não muito útil) manipulando dados do ArcGIS seria:

import os, sys, arcgisscripting

gp = arcgisscripting.create(9.3) #vamos criar um objeto do tipo geoprocessing, versão 9.3

ListaCamadas = gp.ListDatasets(r"C:\teste python\geodatabase.gdb")
#pega uma lista dos featuredatasets no geodatabase.gdb

for camada in ListaCamadas: #para cada camada em ListaCamadas
print camada #imprima camada

#a resposta do Python vai ser algo assim.

>>>>['Hidrografia','Altimetria','Geologia','Transportes']

Bem, vejam como é fácil andar pelas listas e realizar operações em série. Os loops em Python são descomplicadíssimos.

Sugiro que agora, corram ao site da ESRI, e deem uma olhada nos geoprocessing Objetcs. Eles podem facilitar muito a vida de um utilizador de SIG.

Um abraço

Leituras...

Sábado feio de São Paulo...

Ontem comprei dois livros: Aprendendo Python da O'Reilly e o SQL Server 2008 para Desenvolvedores.

Tem que estudaaaar. Mas agora é hora de Antartica.

Abraços

pgRouting - funcionalidades avançadas do PostGIS

Boa noite a todos,

Venho falando muito de PostGIS e PostgreSQL, e hoje não vai ser diferente. Não falarei as history tables, que é um assunto ainda extenso, mas sim do pgRouting.

O que é pgRouting? Bem pgRouting é uma extensão para o PostGIS que vai habilitar o usuário a construir redes e utilizar algoritmos de roteirização, dentro do PostGIS.

Toda rede à ser analisada, dentro de softwares proprietários ou livres, necessitam de um bocado de informação para funcionarem corretamente, e aqui não é diferente. Com uma rede pronta (existem exemplos no site), é possível utilizar diversos alfgoritmos e aplicar pesos a cada "logradouro" ou eixo à ser percorrido, tornando toda esta história de roteirização bastante útil para se encontrar o "melhor caminho".

Os algoritmos disponíveis pelo pgRouting são:

Shortest Path Djisktra;
Shortest Path A*
Shortest Path Shooting Star;
TSP - Travelling Sales Person;
e
Driving Distance calculation;

É bom lembrar que estes algoritmos funcionam em qualquer tipo de rede organizada, seja ela de estradas, rios, de transmissão e tudo mais o que você puder pensar.

Em geral os algoritmos vão retornar ao usuário uma série de linhas, contendo os nós à serem percorridos e os eixos (nodes and edges, para os íntimos).

Esta extensão só mostrar como o PostGIS pode dar ao usuário avançado de GIS um poder que somente se consegue com um Network Analyst (sem contar o armazenamento em banco de dados, flexibilidade de armazenamento, possibilidades de publicar conteúdo na WEB e claro, preço) que custa uns R$10.000,00.

Vão lá, olhem o site e testem.

Abraço

History Tables, denovo.

Boa noite pessoal.

Uns posts atrás falei sobre uma função que permitisse e criasse automaticamente as regras e tabelas para armazenamento de registros históricos no PostGIS.

Bem, aqui vão algumas questões: O PostgreSQL nos permite lidar com este tipo de situação de duas formas: Rules e/ou Triggers.

No caso do nosso projetinho, foram utilizadas rules para lidar com o que precisamos fazer. Bem, o que deve ter um histórico de feições?

Primeiramente ele deve guardar todas as feições inseridas, atualizadas e deletadas, bem como a data, hora, nome do usuário que realizou a alteração, e uma coisa interessante, qual é a versão atual daquela feição. Desta forma podemos rastrear quais foram as alterações históricas de cada versão e caso preciso, achar a versão mais apropriada e restaurá-la para o banco de dados principal.

Além disso, temos um registro histórico de fato. Sabemos todas as alterações de uma feição. É possível entender como um lote mudou, por exemplo, ou como um animal rastreado por GPS está se movimentando. Outra coisa bacana, podemos saber como está evoluindo a cobertura vegetal de uma determinada região. Aumentou? Diminuiu? Não existe ambiguidade ou imperícia. Tudo pode ser restaurado e analisado de acordo com uma dimensão extra, o tempo.

Bem, vou postar aqui a estrutura de uma tabela histórica:

1. CREATE TABLE foo_history(
2. history_id serial not null,
3. date_created timestamp not null default now(),
4. date_deleted timestamp default null,
5. operacao varchar(20) not null,
6. usuario varchar(80) not null default current_user,
7. versao_atual varchar(80),
   
8. LIKE foo,
9. CONSTRAINT foo_history_pk PRIMARY KEY(history_id));

É mais ou menos isso. Deêm uma olhada na linha 8, a expressão LIKE foo. Ela diz ao PostgreSQL que ele deve procurar a estrutura da tabela foo, e copiar ela todinha embaixo. Legal não?

Imagine a tabela foo:

1. CREATE TABLE foo(
2. fid serial not null,
3. classe_vegetacao varchar(30) not null,
4. CONSTRAINT foo_pk PRIMARY KEY(fid));

Nossa tabela foo_history final seria:

1. CREATE TABLE foo_history(
2. history_id serial not null,
3. date_created timestamp not null default now(),
4. date_deleted timestamp default null,
5. operacao varchar(20) not null,
6. usuario varchar(80) not null default current_user,
7. versao_atual varchar(80),
   
8. fid integer,
9. classe_vegetacao varchar(30),
   
10. CONSTRAINT foo_history_pk PRIMARY KEY(history_id));

*Uma particularidade: qualquer campo do tipo SERIAL (como fid, na tabela foo) é realmente do tipo INTEGER. Quando declaramos SERIAL, o PostgreSQL entende que deve criar uma sequência específica para aquele campo e escolhe o valor padrão para aquele campo o próximo valor daquela sequência.

Bem, para começar precisamos de um código SQL que gere automaticamente este código acima. Ele precisa gerar a tabela sem que o usuário digite nada, apenas escolha a tabela que ele quer montar um registro histórico.

Nosso código também precisa montar automaticamente as regras que vão realizar a gestão desta tabelinha acima. Lembre-se que precisamos de uma regra para cada tipo de modificação na tabela, uma para INSERT, uma para UPDATE e uma para DELETE.

Cada uma tem uma particularidade, pois as alterações na tabela histórica não são as mesmas. A regra para delete, por exemplo, não deve criar novo registro na série histórica, apenas indicar que o registro foi deletado.

Não é muito complicado, mas também não é muito simples. Daqui uns dias falo deste códigozinho e dou umas dicas sobre ele.

Novo emprego, novos desafios

Boa noite fellas,

Arrumei um novo emprego, depois de alguns meses meio que parado. O novo emprego na área de mineração e já estou em São Paulo ajudando o pessoal a organizar algumas coisinhas.

Daqui uns tempos, campo! Trecho, Obra, Mato. Chamem como quiserem, mas é bão demais.

"Novas tecnologias": ArcServer, SDE e de volta ao ninho ESRI.

Vamos lá.

George

Contribuindo um pouquinho...

Boa noite pessoar!

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.

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

SIG Portátil?! Isso aí.

Boa tarde pessoal,

Cruzando novamente a internet encontrei em um blog, o Computing, GIS and Archeology, escrito por Jo Cook. Ela desenvolvou um pacote com diversos softwares para GIS para serem utilizados em pen-drives, sem a necessidade de instalação de nada!

Bacana né?

Entre os softwares estão:

Desktop GIS: GRASS, gvSIG e QGIS;

Bibliotecas: GDAL e OGR;

XAMP Lite: Apache (servidor), MySQL (banco de dados) e Php (linguagem de programação);

PostgreSQL 8.2 com PostGIS 1.1

Servidores de Mapas: MapServer, OpenLayers, TileCache, FeatureServer e o GeoServer;

É bastante coisa para colocar em um pen-drive, mas muito legal, já que desta forma não é necessário instalar nada dessa parafernália, testar tudo e além disso mostrar para os outros! Muito mais fácil de mostrar algum trabalho específico para um cliente.

Claro, não é nada para se utilizar em ambiente de produção, mas acho que vale a pena dar uma conferida.

Confiram aí também o Portable GIS.

Esta versão contém softwares mais antigos, mas já existe uma nova versão no forno, contendo todos os softwares atualizados.

Comentários?

George

Aulas gratuitas da Penn State University

Buenas noches pessoal,

Descobri hoje uma coisinha muito bacana: são as aulas de mestrado em GIS da Penn State University nos Estados Unidos. As aulas são gratuitas para qualquer um ler e ver os documentos relacionados com as aulas. Geralmente ekas são direcionadas a parte conceitual do geoprocessamento e geotecnologias em geral.

Existem muitas matérias interessantes e pra quem consegue ler em inglês pode ser uma mão na roda. As aulas são disponibilizadas através de um site chamado Open Educationl Resources.

Estes links que estou passando, se referem somente ao departamento de EMS (Earth and Mineral Sciences). Devem existir com certeza outros departamentos que disponibilizem estas aulinhas excelentes.

Aqui vão alguns exemplos de aulas que o departamento de Geografia deixou na WEB:

Department of Geography

• GEOG 482/160: Nature of Geographic Information
  Author/Instructor: David DiBiase
• GEOG 485: GIS Programming and Customization
  Author/Instructor: Jim Detwiler; Instructors: Frank Hardisty, Tim Enderlein, James O'Brien
• GEOG 583: Geospatial System Analysis and Design
  Author/Instructor: Todd Bacastow
• GEOG 585: Open Web Mapping
  Author/Instructor: Ian Turton
• GEOG 588: Planning GIS for Emergency Managment
  Author/Instructor: Anthony Robinson
• GEOG 860: Comparative GIS
  Author/Instructor: Adena Schutzberg
• GEOG 862: GPS and GNSS for Geospatial Professionals
  Author/Instructor: Jan Van Sickle
• GEOG 863: GIS Mashups for GIS Professionals
  Author/Instructor: Jim Detwiler
  

Só não dá pra fazer os exercícios. Pra isso você tem que ser aluno da Penn State. Mas enfim, fica aí a dica.

Enjoy people!

George Silva

Suporte a VBA descontinuado na versão 9.4

Finalmente a ESRI anunciou o que todo mundo já sabia:

Não iremos ter mais o tão adorado editor VBA na edição 9.4 do ArcGIS/ArcEngine.

O motivo? A própria Microsoft descontinuou o suporte ao VBA em 2008.

A solução agora é migrar todo o código em VB6/VBA para .NET o quanto antes.

A notícia na integra na página do ArcGIS Developer Blog: http://blogs.esri.com/Dev/blogs/arcobjectsdevelopment/archive/2009/03/30/VBA-and-VB6_3A00_-The-Road-Ahead.aspx

Dica: ArcUser

Olá pessoal mais uma vez,

Não sei se vocês conhecem, mas aí vai uma dica interessante:

A ESRI publica quatro vezes por ano uma revista chamada ArcUser, distribuída gratuitamente na internet e para clientes.

É uma revista muito bem editorada, com foco ESRI claro, mas contém dicas interessantes e artigos muito bem escritos.

Deêm uma olhada no artigo desta edição chamado "Speak the Same Language: Making a compelling case for GIS to business executives" - basicamente em português: "Falando a mesma língua: Construindo uma proposta comercial de GIS para executivos de negócios".

O artigo, na verdade uma entrevista com Keith Wishart, um consultor de negócios da ESRI UK descreve de forma interessante os passos para a construção da tal proposta comercial. Ele lista as maiores dificuldades e o que fazer para se dar bem.

A maior dificuldade listada por ele é o grande desconhecimento de executivos seniores da tecnologia GIS. Outro forte da entrevista é a lista de benefícios não-materiais que a implantação de um GIS traz para uma organização.

Fonte: ArcUser Spring 2009 (Speak the Same Language: Making a compelling case for GIS to business executives)

A dica está dada. Além de artigos como este a ArcUser apresenta diversos tutoriais sobre o software ESRI e mostra diversos passo-a-passos.

Aproveitem a leitura.

George Silva