É pessoal… Não foi com surpresa que hoje fiquei sabendo das complicações que o IDESP vem passando. No dia 26 de janeiro de 2010 saiu da presidência do tão esperado IDESP, o pesquisador de renome Peter Mann e entrou o Doutor em Desenvolvimento Econômico pela Universidade Federal do Paraná (UFPR) e professor adjunto da Universidade Federal do Pará (UFPA) José Raimundo Trindade, que vai ter que enfrentar uma dura batalha para não acontecer o que já aconteceu uma vez, a morte do instituto. Pena é …
por editor (noreply@blogger.com) em Fevereiro 08, 2010 12:42
Momento | Crianças indianas a trabalharem com os seus pais num projecto de construção, em frente ao estádio Jawaharlal Nehru, a 30 de Janeiro de 2010, em Nova Deli na Índia. As crianças acompanham os seus pais para o local de trabalho, onde são preparados para trabalhar, recebem dinheiro para os bens necessários, como comida e leite. É a forma de pagamento do empregador.
Fonte: The Big Picture
A equipe de desenvolvimento tem PostGIS, depois de um longo período de reflexão e um auto-exame de vários erros, decidiu lançar PostGIS 1.5.0 para o público. Esta nova versão do PostGIS inclui o novo tipo Geography para de gestão dos dados geodésicos (latitude / longitude), além da melhora no desempenho dos cálculos de distância, GML e KML.
O tipo Geography vai tornar mais fácil para novos usuários armazenarem seus dados no PostGIS (sem ter que aprender sobre projeções e sistemas de coordenadas) e também permitir que os gestores de dados armazenar e consultar seus dados com uma maior eficácia.
http://postgis.org/download/postgis-1.5.0.tar.gz
Fonte: OpenGEO Blog
Para quem gosta de Javascript e aposta em tecnologia como HTML5, Canvas, SVG, etc., este site é um must-to-have nos favoritos.
Este site é um repositório de experiências criadas por diferentes utilizadores, desde designers a programadores, com o intuito de “making the web faster, more fun, and more open”.
http://www.chromeexperiments.com/
por editor (noreply@blogger.com) em Fevereiro 05, 2010 10:48
Población por municipios de Madrid (2008)
Generalmente, el cálculo de los puntos de ruptura de una distribución ha sido tratado habitualmente desde el punto de vista del cliente (gvSIG, Quantum GIS, ArcGIS, etc), descargándose a la aplicación los datos oportunos (shapefiles, PostGIS, etc) para escoger posteriormente algún método de agrupamiento o clustering. Esta solución resulta apropiada cuando los datos a representar proceden de diferentes fuentes, cambios de geometría constantes realizamos muchos temáticos distintos, o cualquier otra variable a considerar. Pero sin embargo, cuando necesitamos representar la misma realidad espacial (municipios, provincias, comunidades autónomas, continentes, etc) desde diferentes aspectos (demografía, economía, agriculturas, etc) no resulta tán cómodo delegar esta función a la aplicación cliente.
Pongamos un ejemplo para clarificar el tema: Imaginemos que disponemos de datos de población agregados a nivel de municipios, donde existen tantas columnas como censos de población se hayan hecho, y deseamos generar en un portal de Internet mapas temáticos a requerimiento del usuario (año del censo, nº de clases, método de agrupamiento o clustering y paleta de colores). Crear un mapa coroplético de la población lleva implícito un conocimiento de la distribución de los datos (valores mínimos y máximos de la serie, media), y sobre todo las medidas de dispersión o de variabilidad: desviación típica, varianza, co-varianza, coeficiente de correlación de Pearson. Con estos parámetros estamos en condiciones de definir cual será el método de cálculo de intervalo de clase más apropiado para nuestra distribución, para posteriormente asignar la paleta de colores acorde al fenómeno a representar (este último aspecto ya lo tenemos solucionado con nuestra clase PHPcolorBrewer). Con una aplicación de GIS de escritorio sólo podemos realizar un mapa para visualizarlo en pantalla o imprimirlo, pero en un ambiente web(GIS) este forma de actuar carece de lógica, pues estamos limitando al usuario la posibilidad de elegir estos parámetros (método de clustering, número de clases y paleta de colores), ya que es muy complicado obtener datos de un GIS y realizar los cálculos de los intervalos de clases en la própia página web (JavaScript, PHP).
Flujo cartografía temática
En este artículo vamos a solucionar esta cuestión proponiendo un método que nos permita desde el servidor, es decir, desde el gestor de base de datos, calcular los intervalos de clase. Para ello no nos queda más remedio que recurrir a la creación de funciones o procedimientos almacenados que contemplen dicha lógica. Realizarlo con PLPg/SQL es una solución, pero programar estas funciones requiere de mucho esfuerzo al no formar parte de las funciones nativas del servidor (por ejemplo, no existe una función que calcule la desviación típica). ¿Por qué no utilizamos un lenguaje especializado en el manejo estadístico? En este sentido, PL/R reúne todas las condiciones para convertirse en el lenguaje de programación elegido. Una prueba de la potencia de este lenguaje, en este caso R lo podemos ver con este ejemplo.
Implementación en R
Tenemos la población activa (valores en miles) de todas las provincias españolas, obtenidas del INE, en el año 1996, disponibles en un objeto vector:
|
c(126.4,137.9,570.9,192.1,409.7,60.2,251.3,325.9,2109.1,145.8,159.4,425.5,207.8,194.3, 172.5,301.5,443,69,252.4,300,55.2,296.4,158.2,84.5,244.3,200.3,141.7,174.2,2180.7, 475.8,438,224.6,161.4,71.2,320.8,390,104.7,144.3,328.3,56.5,646.5,36.3,242,52.8,196.5, 919.6,211.6,473.9,70.2,356.7,50) |
En una sesión de R se crearía de esta manera
|
poblacion.1996 <- c(126.4,137.9,570.9,192.1,409.7,60.2,251.3,325.9,2109.1,145.8,159.4, 425.5,207.8,194.3,172.5,301.5,443,69,252.4,300,55.2,296.4,158.2,84.5,244.3,200.3,141.7, 174.2,2180.7,475.8,438,224.6,161.4,71.2,320.8,390,104.7,144.3,328.3,56.5,646.5,36.3, 242,52.8,196.5,919.6,211.6,473.9,70.2,356.7,50) |
Y se podría ver simplemente escribiendo:
poblacion.1996
Resultado
|
[1] 126.4 137.9 570.9 192.1 409.7 60.2 251.3 325.9 2109.1 145.8 [11] 159.4 425.5 207.8 194.3 172.5 301.5 443.0 69.0 252.4 300.0 [21] 55.2 296.4 158.2 84.5 244.3 200.3 141.7 174.2 2180.7 475.8 [31] 438.0 224.6 161.4 71.2 320.8 390.0 104.7 144.3 328.3 56.5 [41] 646.5 36.3 242.0 52.8 196.5 919.6 211.6 473.9 70.2 356.7 [51] 50.0 |
Para ver un sumario estadístico básico de dicho objeto escribimos:
summary(poblacion.1996)
Con este resultado:
|
Min. 1st Qu. Median Mean 3rd Qu. Max. 36.3 139.8 207.8 320.8 342.5 2181.0 |
Entrando ya en materia, vamos a calcular 5 clases distribuidas por el método de intervalos iguales, es decir, (valor máximo- valor mínimo) / nº intervalos:
seq(min(poblacion.1996),max(poblacion.1996),length.out=(5+1))
Resultado
| [1] 36.30 465.18 894.06 1322.94 1751.82 2180.70 |
Es decir, las clases quedarían agrupadas de esta forma:
Este método, aunque sencillo de implementar (incluso desde la parte cliente) ofrece una clasificación muy distorsionada cuando los valores son muy dispares, por lo que necesitamos recurrir a otros métodos más eficientes, como son los cuantiles. En R este cálculo queda reducido a la mínima expressión:
quantile(poblacion.1996)
Resultado:
|
0% 25% 50% 75% 100% 36.3 139.8 207.8 342.5 2180.7 |
Esta sería nuestra clasificación
¡Más sencillo imposible!
El problema de trabajar directamente en R estriba en la dificultad para obtener datos desde otras fuentes, aunque siempre podemos recurrir a paquetes externos para traer los datos de shapefiles o tablas de PostgreSQL a R
Implementación en PostgreSQL
Como ya hemos visto en anteriores artículos sobre PL/R, esta lenguaje procedural es muy sencillo de utilizar. Sólo hay que copiar el código de R y realizar pequeños cambios para adaptarlo a la sintaxis de PL/R.
Un aspecto que debemos tener muy claro es que casi todos los cálculos en R de una distribución deben de estar dispuestos en forma de un vector. Como es lógico, PostgreSQL no soporta este tipo de dato, pero el lenguaje PL/R si que nos permite una conversión hacia el tipo de datos “array”, ofreciéndonos además una función que realiza todo el trabajo (array_accum)
Por ejemplo, si queremos obtener un array con los datos de la poblacion activa en 1996 (columna t1996t1) de la tabla ine.poblacion_activa, esta es la forma de conseguirlo con SQL:
SELECT array_accum(t1996t1) FROM ine.poblacion_activa;
Y este el resultado:
|
{126.4,137.9,570.9,192.1,409.7,60.2,251.3,325.9,2109.1,145.8, 159.4,425.5,207.8,194.3,172.5,301.5,443,69,252.4,300,55.2,296.4, 158.2,84.5,244.3,200.3,141.7,174.2,2180.7,475.8,438,224.6,161.4, 71.2,320.8,390,104.7,144.3,328.3,56.5,646.5,36.3,242,52.8,196.5, 919.6,211.6,473.9,70.2,356.7,50} |
Con esta pequeña aclaración ya podemos utilizar cualquier columna con datos numéricos para realizar funciones de clustering. Las siguientes funciones de PL/R reproducen los cálculos realizados anteriormente con R:
Función para el método de intervalos iguales:
CREATE OR REPLACE FUNCTION r_equal(double precision[], integer) RETURNS double precision[] AS $BODY$ sort(seq(min(arg1),max(arg1),length.out=(arg2+1))) $BODY$ LANGUAGE 'plr' VOLATILE STRICT COST 100;
Vamos a analizar esta función.
Tiene dos parámetros de entrada:
El resultado (RETURNS) será siempre una estructura de tipo array.
El cuerpo de la función se reduciría a una sola línea que recibe los dos argumentos de la función (arg1 y arg2):
sort(seq(min(arg1),max(arg1),length.out=(arg2+1)))
El uso de esta función es muy sencillo:
SELECT r_equal( array_accum(t1996t1), 5 ) FROM ine.poblacion_activa;
Nos devolverá el siguiente array:
|
{36.3,465.18,894.06,1322.94,1751.82,2180.7} |
Para aquellos más versados en PLPg/SQL habrán advertido que realizar la función en este lenguaje requiere de algunas líneas más de código, que pueden ser bastantes más si queremos utilizar otros métodos, como el de cuantiles, que reproducimos a continuación.
CREATE OR REPLACE FUNCTION r_quantile(double precision[], integer) RETURNS double precision[] AS $BODY$ quantile(arg1,probs = seq(0, 1, 1/arg2)) $BODY$ LANGUAGE 'plr' VOLATILE STRICT COST 100;
Ejemplo de uso para 5 intervalos de clase:
SELECT r_quantile(array_accum(t1996t1),5) FROM ine.poblacion_activa;
Devuelve:
|
{36.3,104.7,174.2,251.3,409.7,2180.7} |
Ahora que tenemos implementado un método para calcular los intervalos de clase ya estamos en condiciones de desarrollar un auténtico motor de cartografía temática (corológica) en un ambiente web que combine la capacidad de cálculo de PL/R con la semiología cartográfica implementada en PHPcolorBrewer que sea capaz de “pintar” geometrias de una tabla espacial de PostGIS. El resultado de esta coctelera explosiva lo podeis ver en las siguientes demostraciones on-line:
Test 1: Distribución de la población activa por provincias (valores en miles de personas)
Este sencillo ejemplo nos permite ver las posibilidades de integración de varias piezas de software (PostGIS, PL/R. PHP MapScripts y PHPcolorBrewer). Los cálculos de los intervalos de clase utilizan el método “Kmeans”, y el usuario tiene la posibilidad de cambiar la paleta de colores y el nº de clases, así como el año que desea consultar.
Test 2: Distribución de la tasa de ocupación/desempleo por Comunidades Autónomas(valores en miles de personas)
Similar al anterior, pero aplicado a CC.AA. Ofrece la posibilidad de múltiples consultas (número de ocupados/desempleados diferenciando hombre, mujeres y total)
Test 3: Distribución de la población activa por provincias (valores en miles de personas) según diferentes métodos de clustering
Este ejemplo es similar al primero, pero hemos añadido la posibilidad de que el usuario selecciones el método de cálculo de intervalos de clase desea. Es sin duda, un buen ejemplo de la potencia que tiene PL/R al permitirnos elegir hasta 8 métodos diferentes:
Test 4: Varios mapas temáticos en una sóla página con todos los métodos anteriores
El objeto de este ejemplo es demostrar de una sóla vez como se representa un mismo fenómeno desde diferentes métodos de clustering, para ver cual es el que mejor se adapta a nuestras necesidades.
Test 5: Mapa temático municipal sensible con HTML dinámico
Se trata del ejemplo más completo de todos, que nos permite seleccionar una provincia y ver la distribución de la población (total, hombres o mujeres) por municipio. También permite seleccionar todos los métodos indicados, así como la paleta de colores y nº de intervalos.
Test 6: Todas las paletas PHPcolorBrewer aplicadas a un mapa temático
El objetivo de este ejemplo es demostrar en una sóla página como un mismo fenómeno es representado con todas las paleta de PHPcolorBrewer, para que el usuario seleccione la que más le convenga.
La creación de cartografía coroplética es quizás uno de los aspectos más recurrentes que podemos encontrar en un ambiente webgis. Todos hemos visto o realizado alguna vez con nuestro programa de GIS favorito un mapa de distribución de la población o cualquier otra variable por municipios, provincias, autonomías o estados. En su preparación siempre intervienen tres elementos: una base cartográfica con datos asociados para representar, un método estadístico para agrupar los datos en intervalos de clase o conjunto de datos, y finalmente una simbología cartográfica aplicada a dichos grupos que represente de una manera clara el fenómeno que deseamos destacar. Los datos a tratar siempre serán de tipo numérico y harán referencia a datos cuantitativos.
PHPcolorBrewer palettes
NOTA: La segunda parte de este artículo lo puede consultar en: Cartografía temática II: Cálculo de intervalos de clase con Pl/R
Sobre este tipo de cartografía siempre han circulado muchos tópicos del tipo: “la mejor manera de representar los datos es con un mapa”, con una clara alusión al uso de mapas en detrimento de largos listados o tablas cuya lectura resulta menos intuitiva que un mapa con colores degradados. También encontramos declaraciones con una percepción negativa sobre los mapas temáticos, “la mejor forma de ocultar datos es con un mapa”, aludiendo esta vez al hecho incuestionable de que un fenómeno dado puede dar diferentes lecturas en función del mayor o menor acierto en la elección de los intervalos de clase, en el sentido de que muchos intervalos dificultan la lectura y pocos generalizan demasiado los datos.
Cuando trabajamos con aplicaciones de escritorio GIS nuestra labor se reduce a indicar el fenómeno a representar, el número de intervalos y como mucho elegir una de las gamas de paletas, para finalmente obtener una distribución más o menos aceptable donde es raro que el usuario intervenga en el proceso estadístico que implica decidir las rupturas de clase. De igual forma ocurre con la gama de colores, donde solemos aceptar los predefinidos, o como mucho definimos una degradación de colores.
Quizás sea por deformación profesional, pero suelo advertir una cierta dejadez del usuario respecto al tratamiento de los colores que intervienen en una distribución normalizada en mucha de la cartografía coroplética existente, utilizando, en la mayoría de los casos, los valores que por defecto nos proporciona la aplicación. Para cualquiera que haya estudiado cartografía, sabe que la simbolización del color es uno de los temás más complejos, que muchas veces delegamos en la aplicación de escritorio, en la que intervienen factores tales como la representatividad de los colores, legibilidad, idoneidad en función de su uso (por ejemplo en un mapa pensado para su impresión no todos los colores son imprimibles), adecuación del número de intervalos al fenómeno estudiado, capacidad del usuario para distinguir colores, y por supuesto la elección de un sistema de agrupamiento (clustering) adecuado.
La doctora Cynthia A. Brewer, profesora del Departamento de Geografía en la universidad estatal de Pennsylvania (http://www.personal.psu.edu/cab38/) ha dedicado su faceta profesional al estudio del color en la cartografía coroplética, dejando como legado una serie de paletas de colores adecuadas para la representación cartográfica que han sido bautizadas con su nombre y utilizadas en muchas publicaciones de renombre, como el Census Atlas of the United States (http://www.census.gov/population/www/cen2000/censusatlas/) e implementadas en muchas otras aplicaciones de GIS (ArcGIS)
Basándonos en su trabajo hemos elaborado una sencilla clase en PHP que nos permite hacer uso de dichas paletas de una manera sencilla para el usuario, susceptibles de ser utilizadas en la elaboración de cartografía coroplética.
Esta utilidad está sujeta a la Apache License 2.0
Esta clase consta de los siguientes métodos:
Dada la vocación web de esta clase se han creado estos métodos:
Con el objeto de facilitar al usuario su implementación se han añadido dos scripts con ejemplos de uso:
1. Listado de todas las paletas de colores: examples.palettes.colorBrewer.php
2. Ejemplos de uso: examples.colorBrewer.php
Finalmente, y como ejemplo de cartografía temática les mostramos algunas demostraciones que utilizan esta utilidad.
por volaya (noreply@blogger.com) em Fevereiro 04, 2010 02:07
Se constituye la Red Iberoamericana de Infraestructuras de Información Geográfica (R3IGeo) a fin de coordinar las actividades que en materia de información geográfica puedan desarrollar las países integrados en la Conferencia Iberoamericana, can el objetivo de aprovechar, difundir y mejorar el conocimiento que en esa materia esté disponible en cada país y así alcanzar la interoperabilidad entre las infraestructuras nacionales de información geográfica de las países que la integran.
por editor (noreply@blogger.com) em Fevereiro 04, 2010 01:04
por volaya (noreply@blogger.com) em Fevereiro 04, 2010 09:59
Ontem a comunidade GeoServer-BR chegou a marca de 350 membros, isso em menos de 3 anos de vida. É muito gratificante ver como esta comunidade tem crescido aqui no Brasil, somos hoje a segunda maior comunidade GeoServer no mundo, só perdendo para a comunidade americana.
O números tem surpreendido não só a mim, como também ao Core do GeoServer, pois só no ano de 2009 foram 166 novos membros, e 1068 mensagens, criando uma média de 89 por mês.
Gostaria de agradecer a todos que tem ajudado de alguma forma essa comunidade a crescer. Se você não participa desta comunidade ainda, cadastre-se no link abaixo:
– http://tech.groups.yahoo.com/group/geoserver/
por editor (noreply@blogger.com) em Fevereiro 03, 2010 11:38
O ano está começando e a equipe do uDig já liberou a versão 1.2 M9. Quem está acostumado a acompanhar o desenvolvimento do uDig sabe que é normal essa quantidade de versões antes da versão final. Nesta versão é utilizado o GeoTools 2.6.1, com uma série de melhorias nos plugins de conexão a banco de dados.
Nesta série 1.2 do uDig destaca grandes idéias que foram implementadas pela comunidade de desenvolvedores. A nova versão da biblioteca Geotools, trouxe além da melhoria na conexão com os bancos de dados, suporte a uma série de novos formatos raster e vetoriais. Uma adição importante é o uso do projeto ImageIO-ext que permite o uso de formatos raster suportados pela biblioteca GDAL.
Ainda será adicionado até a versão final o suporte ao WFS 1.1.0, melhorias no suporte ao ArcSDE que agora é multithread e mais rápido, além do suporte ao GeoWebCache e TileServer via WMS-C.
Fonte: uDig Blog
Este é o primeiro grande lançamento desde a versão 1.6.0 aproximadamente a um ano atrás. Esta nova versão traz uma boa coleção de novos drivers para formatos raster e vetoriais:
- Novos drivers para Raster: BAG, EPSILON, Northwood/VerticalMapper, R, Rasterlite, SAGA GIS Binary, SRP (USRP/ASRP), EarthWatch .TIL, WKT Raster;
- GDAL PCIDSK usando o novo driver PCIDSK SDK por padrão;
- Novos drivers para Vetores: DXF, GeoRSS, GTM, PCIDSK e VFK
- Novos Utilitários: gdaldem, gdalbuildvrt agora compilados por padrão
- Adicionado suporte ao Python 3.X, mantendo a compatibilidade com Python 2.X;
- Melhoras significativas nos seguintes drivers raster: GeoRaster, GeoTIFF, HFA, JPEG2000 JasPer, JPEG2000 Kakadu, NITF
- Melhoras significativas nos seguintes drivers vetoriais: CSV, KML, SQLite/SpataiLite, VRT
Fonte: Mateusz Loskot
Tentado a experimentar novos aplicativos para Linux, fui em busca de um aplicativo a quem muito resisti de prová-lo em tempos passados. E ele se chama Thuban. Nesses idos busquei me informar há quantas andava o projeto e não me animei muito. De lá para cá deu para perceber que o projeto não evoluiu muito, mas sua simplicidade em manuseá-lo me chamou a atenção.
O Thuban é basicamente um visualizador para dados de SIG escrito em Python e pode ser facilmente expansível através de plugins. Segundo o site do desenvolvedor ele possui uma interface amigável e alguns recursos úteis, como:
O programa é extremamente leve e possui os recursos mais elementares tanto para quem é leigo em geotecnologias quanto para aqueles que pretendem iniciar a usar aplicativos de SGI. Vou mais além, pode sim ser usado por pessoas ou repartições que não querem se aprofundar em consultas aos dados espaciais, apenas visualizar as feições topológicas dos arquivos recebidos, entre outras utilizações. Com certeza passarei a adotá-lo no meu trabalho, no qual inicializarei os próximos estagiários para irem se familiarizando com as ferramentas para geoprocessamento.
De todas as ferramentas das quais experimentei, a que mais me agradou foi a exportação dos temas em tela para o formato .SVG. Por quê digo isso? Às vezes, preciso de algumas ilustrações, nas quais preciso editar os dados sem compromisso com as normas, como por exemplo para apresentações ou ilustrações e, isto é muito válido para ser utilizado no Inkscape. Chego até a comparar esta funcionalidade com a exportação do .EMF ou .WMF provenientes do Arcgis para ser editado do CorelDraw. Mas o que mais me impessionou foi a qualidade da exportação; muito superior a do Arcgis.
DOWNLOAD E INSTALAÇÃO
Como o programa está nos repositórios oficiais do Ubuntu 9.10, para instalá-lo basta apenas digitar no terminal o seguinte comando como super-usuário:
$ sudo apt-get install thuban
Depois de instalado, basta usá-lo. Espero fazer um bom uso do programa.
Abaixo algumas screenshots do programa.
Adicionando um layer
Shapes adicionados
Exportando para SVG
SVG aberto no Inkscape para edição
Até a próxima pessoal…
por Edmar Moretti (edmar.moretti@terra.com.br) em Fevereiro 02, 2010 07:30
A partide hoje os leitores que estiverem acessando o blog com um iPhone, iPod Touch, Android ou BlackBerry Storm terão uma versão mais amigável, isso porque instalei aqui no blog o plugin wptouch que automaticamente detecta se o usuário está acessando a partir de um iPhone/iPod e muda a interface para obter uma melhor interface.
Se você também deseja tornar seu blog “iPhone Friendly”, de uma olhada no roteiro no blog Heric Tilly.
por editor (noreply@blogger.com) em Fevereiro 02, 2010 07:43
por volaya (noreply@blogger.com) em Fevereiro 01, 2010 10:24
Está en marcha la convocatoria de requerimientos para los temas de los Anexos II y III de INSPIRE.
por editor (noreply@blogger.com) em Fevereiro 01, 2010 08:52
por Lisete Osório (noreply@blogger.com) em Janeiro 30, 2010 10:46
Teste
Il s’agit d’un billet temporaire qui n’a pas été supprimé. Supprimez-le manuellement. (cae75042-7fd2-45bb-8162-063a763fea0a - 3bfe001a-32de-4114-a6b4-4005b770f6d7)
Mobile GeoRSS Maps combina a Google Maps API com a Google Feeds API para exibir um feed GeoRSS em um mapa otimizado para o visor do celular.
Você pode a partir dele simplesmente adicionar o mapa no seu celular, ou gerar um link do mapa para o seu e-mail, além de possuir opções de personalização como definir a cor dos marcadores, o tipo de mapa padrão, entre outras fucionalidades.
Criar um link para o seu celular com o Mobile GeoRSS é apenas uma questão de segundos. Tudo que você precisa fazer é adicionar um feed GeoRSS ou a saída de um GeoRSS do My Google Map que vai lhe dar um link onde você pode acessar o mapa pelo celular.
O Mobile Maps GeoRSS funciona em qualquer telefone que tenha suporta a Maps API v3, como o iPhone e o Android.
Fonte: Google Maps Mania
El catálogo se ha desarrollado con tecnologías Open Source y usa UMN MapServer como servidor de mapas. La aplicación web hace uso de técnicas AJAX y cumple estándares W3C, con la intención de que se ejecute sin problemas en la mayoría de sistemas y navegadores sin necesidad de tener que instalar ningún plug-in ni software adicional en el ordenador del usuario
Depois de tanto insistir em fazer meu GPS Garmin etrex vista HCx funcionar no Ubuntu, desisti por várias vezes de fazê-lo baixar meus dados. Até que, hoje, eu decidi acabar de vez com esse “mal-assombro” que há tanto me perseguia. Garimpei pelos sites estangeiros, até dar aquele estalo e perceber que a solução estava debaixo do nariz. Digo mais: precisei “fuçar” todos os programas possíveis e imagináveis no universo linux para GPS. Ressalto que trabalhar com GPS com uma interface Serial sempre foi muitíssimo fácil no Linux.
A solução foi a seguinte:
1. Baixe e instale o programa GPSBabel no seu Ubuntu. Via terminal/console o comando é o seguinte (em modo super-usuário):
$ sudo apt-get install gpsbabel
2. Depois de baixado e instalado, espete seu GPS na interface USB e ligue-o.
3. Ainda no terminal vá até a pasta onde você quer que seus dados sejam descarregados. Para isto, use o comando:
$ cd nome_da_sua_pasta
4. Cumprida a etapa anterior, é hora de descarregar seus dados do GPS. Então, digite o seguinte comando:
$ sudo gpsbabel -t -i garmin -f usb: -o gpx -F nome_do_seu_arquivo.gpx
Para baixar os dados track (trilhas) use o argumento -t após o nome do programa (gpsbabel)
Para baixar os dados waypoints (pontos), substitua o argumento -t por -w
Para baixar os dados route (rotas), substitua o argumento -t por -r
Deixo como dica ainda que, o formato dos arquivos baixados podem ser KML (formato do Google Earth) e GTM (formato do Trackmaker). Para descarregar num desses dois formatos é necessário apenas que o argumento seja alterado. Onde houver gpx na linha de comando acima, substitua por kml ou gtm. Não esqueça de mudar também a extensão do seu arquivo.
Eu prefiro trabalhar com o formato GPX e depois convertê-lo em Shapefile.
Espero que você não tenha quebrado a cabeça tanto quanto eu. Faça um bom proveito da dica e caso tenha algo a acrescentar, deixe uma mensagem para contribuir com a difusão do conhecimento.
Até a próxima dica.
PS: Não testei se funciona com outros receptores GPS. Portanto, não sei se funcionará com seu aparelho. Mas, como não há nenhuma especificação nos comandos em referência a modelos, acredito que deve funcionar sim noutros equipamentos Garmin.
En este artículo usaremos una librería de R (“fields”), que contiene métodos para calcular el semi-variograma empírico de una imagen, lo cual quiere decir que calcularemos el semi-variograma de una gran cantidad de puntos. Y a partir de ahí, analizaremos la existencia de patrones espaciales en tres parcelas agrícolas arbóreas.
Espero que este sea el primero de varios posts donde aprendamos a estudiar las ortoimagenes, extrayendo características de distintos tipos como ya hicimos en un post anterior (http://www.gisandchips.org/2009/11/11/procesamiento-de-imagenes-digitales-con-c-y-una-aplicacion-para-el-analisis-de-parcelas-agricolas/ ). En aquel caso, se extrajeron algunas sencillas frecuencias a partir del cálculo de la Transformada de Hough que nos proporcionaba AForge.NET, lo cual nos servía para automatizar la decisión de si una parcela era una plantación arbórea y realizar un conteo automático del número de árboles que contenía. En dicho post, se ofrece una aplicación llamada RAPID, que incorpora una galería de imágenes de parcelas agrícolas. Hemos extraído tres de ellas para realizar los siguientes análisis. Son las siguientes:
Al estudiar las 3 parcelas que aparecen en la Figura 1 con el RAPID: La primera es identificada totalmente como agrícola y nos permite contar con bastante certidumbre el número de árboles de un modo automático. En el caso de la segunda, su estructura en hileras no permite el conteo de árboles pues están muy juntos. Y por último, en los olivos de la tercera no se cumplía la regla de una estructura normal, aunque sí que podíamos contar los árboles. Este último caso era el único donde RAPID no podía “acertar” pues identificaba la parcela como no agrícola debido a que la diferencia angular entre las direcciones principales de la Transformada de Hough no se aproximaba a 90º.
¿Qué es un variograma experimental? (una breve explicación para entender los resultados)
Los variogramas se utilizan para caracterizar la posible estructura espacial de un conjunto de datos. Podemos distinguir dos tipos de variogramas, el experimental y el modelizado. De estos nos interesa más el experimental. Este último se usa para describir los datos de una muestra, habitualmente una nube de puntos (xyz)
Matemáticamente el semi-variograma, o variograma/2, se puede definir como la mitad del promedio de las diferencias al cuadrado.
Donde Np(h) es el número de pares a la distancia h, h es el incremento.
Z(xi) son los valores experimentales.
xi localizaciones donde son medidos los valores z(xi).
Aplicado a imágenes, el semi-variograma (o variograma/2), mide el grado de correlación espacial entre los píxeles de una imagen. Podemos comentar varios conceptos (ver Figura 3):
Ejemplos de cálculo en R
Os aviso de que las imágenes referidas en el código estan en formato *.ppm aunque R tiene muchas librerías capaces de convertir a este formato. También podéis utilizar OpenOffice.
En este post, aplicamos el siguiente código para calcular el semi-variograma empírico de cada una de estas imágenes:
<pre># Instalo los packages necesarios:
#-------------------------------------------------
install.packages("pixmap", dependencies= T)
install.packages("fields", dependencies= T)
# Cargo las librerias:
#-------------------------------------------------
library(pixmap)
library(fields)
# Hago una lista con las imagenes de las parcelas y las cargo todas:
#-------------------------------------------------
imag_dir <- list.files("C:\\ ... \\Articulos Gisandchips\\ parcelas_ppm\\", full.names=T)
parcela1 <- read.pnm(imag_dir[1])
parcela2 <- read.pnm(imag_dir[2])
parcela3 <- read.pnm(imag_dir[3])
# Aislamos una banda...
#-------------------------------------------------
matriz1<-parcela1@green
matriz2<-parcela2@green
matriz3<-parcela3@green
# Calculamos el semivariograma (si queremos podemos acabar antes cambiando el alcance de 40 a 10, por ejemplo, pero los resultados pueden cambiar y quedará menos bonito (-: )
#-------------------------------------------------
vgram1_40<-vgram.matrix( matriz1, R=40) # esto llevará un poco de tiempo
vgram2_40<-vgram.matrix( matriz2, R=40) # esto llevará un poco de tiempo
vgram3_40<-vgram.matrix( matriz3, R=40) # esto llevará un poco de tiempo
# Añadimos al Plot las matrices que acabamos de calcular
#-------------------------------------------------
plot.vgram.matrix(vgram1_40)# La matriz del variograma
plot.vgram.matrix(vgram2_40)# La matriz del variograma
plot.vgram.matrix(vgram3_40)# La matriz del variograma
# Creamos una curva que ajuste bien sobre la muestra y la añadimos al variograma
#-------------------------------------------------
polyfit1_40_20 <- lm(vgram1_40$vgram ~ poly(vgram1_40$d, 20));
plot(vgram1_40$d, vgram1_40$vgram)
lines(sort(vgram1_40$d), polyfit1_40_20$fit[order(vgram1_40$d)], col=2, lwd=4)
polyfit2_40_20 <- lm(vgram2_40$vgram ~ poly(vgram2_40$d, 20));
plot(vgram2_40$d, vgram2_40$vgram)
lines(sort(vgram2_40$d), polyfit2_40_20$fit[order(vgram2_40$d)], col=2, lwd=4)
polyfit3_40_20 <- lm(vgram3_40$vgram ~ poly(vgram3_40$d, 20));
plot(vgram3_40$d, vgram3_40$vgram)
lines(sort(vgram3_40$d), polyfit3_40_20$fit[order(vgram3_40$d)], col=2, lwd=4)
El plot que obtenemos es el siguiente, o similar si es que hemos preferido cambiar algún parámetro:
En la imagen vemos las parcelas, la matriz de su variograma y el variograma, con una curva que ajustamos mucho al los datos. Es fácil interpretar que en la estructura de las parcelas se llega a apreciar cierta “ciclicidad”, ya que encontramos mesetas a distintas distancias. Cada meseta se corresponde aproximadamente a las hileras de árboles. El alcance es el que hemos definido (40, en este caso 40 píxeles; puede que unos 20 m. en la realidad).
Viendo estas imágenes nos podemos dar cuenta de que es más fácil determinar una regla de clasificación que cuando lo hacíamos en el caso del RAPID. En este caso, nos fijamos en el número de máximos relativos de la función polinómica de ajuste del variograma. A simple vista, la primera parcela tiene unos 4, la segunda apenas 1 y la última 3 o 4. En este caso, podríamos citar una nueva regla para nuestro programa según la que a partir de 2 o 3 máximos relativos una parcela puede ser considerada una plantación arbórea.
Como nos interesa automatizar la tarea creamos una función que nos cuente los máximos relativos. Aquí viene el ejemplo aplicado a la primera parcela:
# Encontrar máximos relativos en la función 1
#--------------------------------------------------
maxRelativos1=0
hMaxRelativos1=0
for(i in 1:(length(polyfit1_40_20$fitted.values)-1))
{
if (polyfit1_40_20$fitted.values[i] > polyfit1_40_20$fitted.values[i+1] && polyfit1_40_20$fitted.values[i] > polyfit1_40_20$fitted.values[i-1])
{maxRelativos1[i]<- polyfit1_40_20$fitted.values[i]
hMaxRelativos1[i]<- vgram1_40$d[i]}
}
MaxRelativos1<-data.frame(hMaxRelativos1,maxRelativos1)
MaxRelativos1<- na.omit(MaxRelativos1)
NumMaxRelat1_40<-length(rownames(MaxRelativos1))
Consultamos los vértices de la curva que hemos dibujado mediante un bucle, de modo que si el vértice i tiene un valor superior al vértice anterior y también al vértice posterior entonces es considerado un máximo relativo y queda almacenado en la lista.
(1) El semivariograma implica un gran esfuerzo de cálculo por parte del ordenador. Esto hace que aún habiendo varias librerías en R que obtienen el semivariograma de una nube de puntos, sean significativamente más lentas que Fields. Además, Fields hace directamente lo que necesitábamos. No obstante, en un futuro no muy lejano, intentaré desarrollar una librería en C# para reproducir un análisis de este tipo y otras cosillas relacionadas.
(2) Por cuestiones de tiempo no he tratado de crear funciones para las distintas etapas de la demostración. Puede ser un buen ejercicio tratar de implementar todo esto en funciones que permitan entre sus parámetros especificar la banda con la que trabajar, el alcance del semivariograma…
(3) Existen más posibilidades a la hora de establecer reglas, por ejemplo podríamos explorar la distancia que separa los máximos relativos para distinguir los cultivos más intensivos de los más tradicionales. Se me ocurren muchas más posibilidades.
(4) Por último, aunque no le doy mucha importancia, deciros que el número de máximos relativos no es del todo correcto pues el cero siempre aparece en el conteo (sale 5, 2, 5 y no 4, 1, 4 como he dicho más arriba), esto es porqué no he trabajado bastante el bucle, pero es fácil restar 1 a la lista final. Mi idea principal es la de explorar el concepto y dar unos ejemplos de código a modo de ideas.
Para entender bien todo esto creo que es interesante ver mi artículo anterior…
Solamente os remito al siguiente tutorial de Surfer. Es bastante didáctico. http://www.goldensoftware.com/variogramTutorial.pdf
De todos modos la red está llena de materiales, apuntes de clase, libros en PDF… No tendréis problemas en encontrar información sobre los variogramas.
——————————————————————-
Si quereis contactar podeis enviarme un email (asunto: gisandchips):
Benito M. Zaragozí
benito.zaragozi@ua.es
Landserf é um aplicativo desenvolvido por Jo Wood do Departamento de Ciência da Informação da Universidade de Londres. Basicamente, o software constrói e visualiza paisagens em três dimensões e efetua análise geomorfológica. Por ser desenvolvido em Java roda nas plataformas Linux, Unix, MacOSX e Windows.
As principais características, segundo o site do software são:
INSTALAÇÃO NO UBUNTU 9.10
Primeiramente deve estar instalado no computador o ambiente Java. Para isto, clique em Aplicativos > Central de Programas do Ubuntu.
Em seguida, no campo de busca digite Java. Clique na opção Sun Java 6 Runtime e depois na seta. Depois clique em instalar.
Feito isto, é hora de baixar e instalar o programa. Para baixar, clique no link do site do desenvolvedor: http://www.soi.city.ac.uk/~jwo/landserf/download/. Será requisitado que seja preenchido um pequeno formulário (só para fins estatísticos do desenvolvedor).
Baixe a versão atual 2.30 (landserf230LinuxInstall.jar). São aproximadamente 13,2 MB. O arquivo está em formato do Java.
Para instalar basta ir, através do terminal, para a pasta onde o download foi efetuado e executar o seguinte comando:
$ java -jar landserf230LinuxInstall.jar
Pronto. Seu programa está instalado. Para executar o programa via terminal, basta digitar: ./landserf.sh. Se não quiser executá-lo pelo terminal, basta inserir um lançador no menu ou desktop.
Tela principal do aplicativo
Aqui, você pode baixar o manual e tutorial do programa. Espero que façam bom proveito. Até a próxima.
Website do desenvolvedor: http://www.soi.city.ac.uk/~jwo/landserf/index.html
Forum de discussão (em inglês): http://vega.soi.city.ac.uk/~jwo/landserf/forum/
por Edmar Moretti (edmar.moretti@terra.com.br) em Janeiro 28, 2010 12:01
Klencke é o maior atlas do mundo, em termos de dimensões, alguma vez criado. Foi oferecido ao rei Charles II de Inglaterra, aquando da restauração da monarquia em Inglaterra e na Escócia. Nunca tinha sido mostrado ao grande público. Passados 350 anos da sua publicação, é possível ver esta grande obra de arte no British Museum, Londres, numa exposição intitulada de “Mapas Magníficos: Poder, Propaganda e Arte”. Para se ter uma ideia das dimensões, 1.75m de altura por 1.9m de largura, Klencke necessita de seis pessoas para o levantar e transportar.
Esta mega publicação é composta por 100 mapas, incluindo um mapa-mundo desenhado por portugueses.
Porém, nesta exposição para além de ser possível ver o maior atlas é também possível ver o mapa mais antigo do mundo. Trata-se do mapa do Império de Roma datado de 200 anos antes de Cristo.
ESRI ha organizado un campeonato para creación de mashups innovadores y en donde es requisito imprescindible usar ArcGIS Online y la Web Mapping APIs de ESRI. Se premiará la originalidad, la creatividad y los procesos de análisis que se han llevado a cabo. También piden realizar un vídeo de la aplicación y enviarlo a YouTube. La cuantía de los premios va de los $10.000 a los $2.500. El plazo de inscripción termina el 5 de Marzo de 2010.
No último post foi falado sobre o problema de segurança dos serviços REST no GeoServer, que foi corrigido para GeoServer 2.0.1. Um patch foi criado também foi para a versão 1.7.x e já está disponível. Todos os usuários que utilizam o plugin restconfig com o GeoServer 1.7.x devem instalar o patch. Note que, as regras descritas no último post são aplicáveis na versão 1.7.x após a instalação do patch.
O Flex for Kids é uma maratona de palestras on-line que será realizado no dia 06/02/2010 e contará com grandes nomes da comunidade Adobe Flex brasileira.
Serão 10 palestras on-line ao vivo durante o dia inteiro, usando um ambiente de eventos multimídia onde os palestrantes ministrarão seus temas através de recursos de áudio, vídeo, slides e chat.
Flex for Kids 2010 from e-Genial on Vimeo.
Qualquer pessoa, empresa ou faculdade poderá participar do Flex for Kids, para isto basta fazer uma doação de um valor simbólico de R$ 30,00 para ter acesso as 10 palestras on-line e suas gravações que serão disponibilizadas 15 dias após o evento.
Todo dinheiro arrecadado será doado ao Cotolengo de Mato Grosso do Sul.
por Edmar Moretti (edmar.moretti@terra.com.br) em Janeiro 27, 2010 12:47
Uma característica que se tornou bastante popular no GeoServer no último foi o plug-in RESTful, que permite a configuração de uma instância do GeoServer programaticamente através de requisições HTTP.
Recentemente, a questão da segurança tem surgido com relação ao plugin. Essencialmente, resume-se ao fato de que GeoServer permite o acesso anônimo a qualquer recurso ou serviço quando o método de solicitação HTTP é o GET. No caso do restconfig isso pode tornar disponíveis informações sensíveis de forma anónima, como parâmetros de conexão do banco de dados que podem conter as senhas de acesso.
Para resolver essa situação na versão 2.0.1 do GeoServer o sistema de segurança foi ampliado para permitir a configuração de acesso a serviços RESTful.
Uma ressalva importante para os usuários que atualizarem para a versão 2.0.1 é que qualquer sistema que dependia do comportamento anterior de acesso GET para recursos sem autenticação, sem dúvida, deve parar de funcionar. Neste caso, os usuários têm duas opções:
1. Começar a fornecer credenciais de administrador com todos os pedidos
2. Reconfigurar o GeoServer para permitir o acesso anônimo para operações GET
Nota: este artículo lo hemos escrito dos Jorges, un servidor y Jorge Batista (aka PB), compañero de armas de OSGeo-ES y como residente en Cuba desde que fue su madre lo trajo al mundo, sufridor de este sinsentido en el que vamos a ahondar a continuación.
As one of the first companies to promote the adoption and distribution of free and open source software, and one that still puts open source at the center of its corporate ideals, restrictions on the free flow of information rub us the wrong way. However, in addition to participating in the open source community, we also live in the real world, and are governed by the laws of the country in which we are located. Our need to follow those laws supersedes any wishes we might have to make our community as inclusive as possible. The possible penalties for violating these restrictions include fines and imprisonment. Other hosting companies based in the US have similar legal and technical restrictions in place.
Esta situación también la sufren los usuarios de Google Code. Fue de hecho la principal razón para que SEXTANTE se fuera de Google Code a OSOR.eu.
Así a bote pronto se me ocurren situaciones muy extrañas:
Como miembro de OSGeo.org, me preocupa esta situación. No podemos mirar para otro lado pensando en que mientras nadie nos diga nada, mejor estar calladitos y no remover más el merder, como decimos en mi tierra. Vale que no es cuestión de pegar la espantada, ni se catastrofistas o volvernos todos locos, pero tampoco es de recibo ser ajenos a esta situación y que luego nos pille el toro.
De momento SourceForge es uno más que se alinea en “el otro bando”, sus razones tendrá. El software es hoy menos libre, eso sí, en nombre de la libertad; y los cubanos seguimos padeciendo restricciones y medidas originadas por diferencias políticas. ¿Qué nos queda? Pues buscar alternativas y seguir pa’lante. Ah y no quedarnos callaos, que sepan que tienen un enemigo digno.
Un saludo.
PB y XuRxO
por Eduardo Patto Kanegae (noreply@blogger.com) em Janeiro 26, 2010 07:47
por Paulo Carvalho (noreply@blogger.com) em Janeiro 25, 2010 10:44
por Edmar Moretti (edmar.moretti@terra.com.br) em Janeiro 24, 2010 05:01
Quem lida com geoprocessamento, em algum momento de suas vidas precisaram ou precisarão mexer com arquivos CAD, (Computer-Aided Design). Em português: Desenho Auxiliado por Computador.
Geralmente, os formatos de arquivos mais utilizados são .DWG (AutoCad), .DGN (Micro Station) e .DXF (padrão de intercâmbio dos softwares de CAD.) No QCad lê .dwg e .dxf e escreve apenas .dxf.
O QCad é uma alternativa no mundo Linux ao “todo-poderoso” Autocad. Os recursos são, digamos, um pouco limitados mas, no meu caso, que só utilizo ferramentas Cad para algumas funções básicas, me é mais do que suficiente (pode não ser o seu caso).
Em princípio, o QCad é uma ferramenta multiplataforma comercial e, portanto possui uma licença fechada. Mas em compensação, existe uma versão Community Edition que é distribuída sob a licença GNU GPL, pois o desenvolvedor libera parte do código-fonte para a comunidade. Então, qual é a diferença? Basicamente, a primeira, por ser comercial, possui mais recursos. O preço da licença é de apenas 24 euros (em torno de 70 reais). E, a versão Comunitária, possui poucos recursos. É esta a versão que utilizo pois está liberada sob uma licença livre e está nos repositórios do Ubuntu. Para instalá-lo, vá no terminal e como super-usuário digite:
sudo apt-get install qcad
São aproximadamente 14 MB de download que se instalam automaticamente. Para maiores informações acesse o site do desenvolvedor no Brasil http://www.ribbonsoft.com/pt-br/.
Janela do QCad mostrando um retângulo envolvente de uma área de interesse utilizado num mapeamento. Detalhe em vermelho para as coordenadas UTM.
Con ese título se cierra el cuestionario de inscripción a GEOSTAT 2010, el curso de verano de geoestadística que se está planificando para julio de este año en Plasencia. Y uno puede pensar al ver la pregunta (yo lo hice) ¿¡pero estos de qué van!? y la respuesta es sencilla: este curso se viene realizando desde hace tiempo y da la casualidad de que varios de los profesores son músicos (no sabría decir a qué nivel exactamente) y parece que se ha instituido el hacer algún conciertillo durante el curso.
En fin, a ver si se alinean los planetas y puedo asistir este año, me apetece muchísimo, aunque evidentemente a la banda poco voy a poder aportar, ¡espero que no sea un criterio de selección de asistentes!
Local: Auditório Microsoft, Tagus Park, Lisboa
Destinatário(s): Implementador de TI, Programador Não Profissional e Programador Pro.
Inscrição Online: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032440904&Culture=pt-PT
Descrição
Os desafios que hoje são colocados assumem uma tal dimensão e complexidade que as respostas só podem ser encontradas na utilização das melhores tecnologias disponíveis no mercado, com base na inovação, conhecimento, experiência, complementaridade e continuidade, e numa visão assente na partilha e parceria.
Neste evento serão abordadas as vantagens competitivas aportadas pelas tecnologias de informação geográfica, as diversas componentes que podem fazer parte de uma arquitectura (gestão de dados, servidor, desktop, mobile e online), bem como os recursos que a ESRI disponibiliza à comunidade de developers para que estes possam tirar partido das suas soluções. Será dado particular foco, incluindo demonstrações, a:
· ArcGIS API for Microsoft Silverlight™/WPF™
· ArcGIS API for JavaScript, Bing Maps Extension
· ESRI Parts for Microsoft SharePoint
· ArcGIS Mobile
· ArcGIS Online
Agenda
14h00 Registo
14h30 Abertura – As vantagens da análise geográfica
15h15 Arquitecturas SIG e alinhamento com a plataforma Microsoft
15h45 Pausa para café
16h00 Recursos para Developers Microsoft
17h30 Encerramento
por Edmar Moretti (edmar.moretti@terra.com.br) em Janeiro 22, 2010 06:06
Este artigo nasceu num desses momentos, e da necessidade de determinar quais as opções existentes no MapServer, e saber qual delas é a melhor.
AVISO – artigo longo, com resultados de uma série de testes!!! Conclusões no final para os mais stressados…
Imaginemos um pequeno concelho que tem uma colecção de 45 ortofotomapas, em formato TIFF, não comprimido. Cada imagem ocupa 234MB, o que totaliza 10GB de imagens.
O objectivo é publicar estas imagens como uma cobertura que abrange o concelho, numa aplicação webgis, servida pelo MapServer.
Para escolher a melhor forma de publicar as imagens é preciso saber o que é mais importante para nós: velocidade ou espaço em disco?
A verdade é que a compressão das imagens impõe uma penalização na velocidade com que os programas conseguem mostrar essas imagens. Essa penalização pode ser muito pequena ou muito grande, consoante o tipo de compressão e o tipo de imagem criada durante o processo de compressão. Geralmente, os ficheiros ECW e SID são extremamente comprimidos e relativamente rápidos. Em geral também, o formato JPEG2000 comprime muito as imagens mas é lento. O formato mais antigo JPEG é um compromisso entre os 2 grupos anteriores. Outra regra: assume-se que o MapServer é mais rápido com o formato TIFF, sem compressão, do que com formatos comprimidos, mas estas imagens ocupam muito mais espaço em disco.
Portanto, se a sua única preocupação é velocidade, e tem espaço em disco que não se importa de gastar com os seus ortofotomapas, em principio já sabe a sua resposta – use TIFFs sem compressão. Mas nada como verificar se esta “verdade” realmente se aplica aos seus dados em particular. Ahh, e não se esqueça de considerar o tráfego que vai gerar na rede se quiser usar os ortos em programas SIG desktop…
Temos ainda de saber como criar um layer em MapServer que use todas as imagens como um conjunto único. Afinal não quer que o utilizador seja obrigado a ligar 45 imagens uma-por-uma.
Para iniciar os testes converteram-se todas as imagens para os diversos formatos. Os tamanhos totais em cada formato ficaram assim:
| Formato | Dimensão |
|---|---|
| TIF+overheads | 13,5 GB |
| JPG+overheads | 915 MB |
| ECW | 605 MB |
| JP2 | 509 MB |
Os tamanhos indicados incluem imagens de resolução reduzida, chamadas overheads ou pirâmides. Mais sobre isto adiante…
Para ver os comandos de conversão do GDAL para cada formato pode consultar este artigo anterior – GDAL: Formatos comprimidos.
Um mosaico de imagens em MapServer é um layer do tipo RASTER que aponta para um conjunto de imagens em vez de uma só.
A forma tradicional de referenciar um mosaico é criando um shapefile que contém um quadriculado com as extensões das imagens. Este shapefile é criado com um comando do GDAL chamado gdaltindex.
Mas há uma nova opção. Podemos usar o formato VRT, um formato virtual que é constituído por um ficheiro de texto que indica a fonte dos dados e a forma como são organizados. Um ficheiro VRT pode listar um conjunto de imagens de forma a que o MapServer e outras aplicações o leiam como uma imagem única, quando na verdade será composto por todas as nossas imagens. O comando para criar um mosaico VRT é o gdalbuildvrt.
Por último, temos a opção de força bruta: juntar todas as imagens numa só, criando uma imagem enorme em disco que abrange toda a nossa área de interesse. Ou seja, no nosso caso em estudo esta imagem teria 10GB. Para criar este mosaico monolítico usamos o comando gdal_merge.
Vamos ao longo do artigo analisar cada opção e no final medir os tempos que o MapServer demora a visualizar cada tipo de mosaico.
O GDAL suporta um formato virtual, VRT, que lista ficheiros já existentes e os descreve como um todo. Podemos agregar várias imagens numa só, definir um novo sistema de coordenadas, ou no caso de ficheiros vectoriais definir filtros de atributos, e renomear atributos, tudo sem alterar os ficheiros originais. Os ficheiros VRT são ficheiros de texto em formato XML e podem ser editados manualmente, ou criados com o gdal_translate ou com o comando gdalbuildvrt. Mais info aqui.
Para construir um mosaico a partir das imagens numa directoria, basta usar o seguinte comando:
gdalbuildvrt mosaico_tif.vrt directoria\*.tif
O ficheiro “mosaico_tif.vrt” é criado com o seguinte conteúdo:
<VRTDataset rasterXSize="40000" rasterYSize="20000">
<SRS>LOCAL_CS["unnamed",UNIT["metre",1,AUTHORITY["EPSG","9001"]]]</SRS>
<GeoTransform>-1.6000000000000000e+004, 5.0000000000000000e-001, 0.0000000000000000e+000,-7.0000000000000000e+004, 0.0000000000000000e+000,-5.0000000000000000e-001</GeoTransform>
<VRTRasterBand dataType="Byte" band="1">
<ColorInterp>Red</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT="1">tif\003941Argbx.tif</SourceFilename>
<SourceBand>1</SourceBand>
<SourceProperties RasterXSize="8000" RasterYSize="10000" DataType="Byte" BlockXSize="8000" BlockYSize="1"/>
<SrcRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
<DstRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
</SimpleSource>… seguem-se as restantes imagens em sucessivos SimpleSource até terminar a lista de imagens, para a 1ª banda. Depois inicia-se a 2ª banda:
</VRTRasterBand>
<VRTRasterBand dataType="Byte" band="2">
<ColorInterp>Green</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT="1">tif\003941Argbx.tif</SourceFilename>
<SourceBand>2</SourceBand>
<SourceProperties RasterXSize="8000" RasterYSize="10000" DataType="Byte" BlockXSize="8000" BlockYSize="1"/>
<SrcRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
<DstRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
</SimpleSource>… seguem depois as imagens para compor a 3ª banda…
</VRTRasterBand>
<VRTRasterBand dataType="Byte" band="3">
<ColorInterp>Blue</ColorInterp>
<SimpleSource>
<SourceFilename relativeToVRT="1">tif\003941Argbx.tif</SourceFilename>
<SourceBand>3</SourceBand>
<SourceProperties RasterXSize="8000" RasterYSize="10000" DataType="Byte" BlockXSize="8000" BlockYSize="1"/>
<SrcRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
<DstRect xOff="0" yOff="0" xSize="8000" ySize="10000"/>
</SimpleSource>Finalizando-se o ficheiro assim:
</VRTRasterBand>
</VRTDataset>O QGIS 1.4.0 consegue ler este tipo de ficheiro, mostrando-o como uma só imagem:
Mosaico VRT visualizado no Quantum GIS 1.4.0.
Mas a performance é um problema. Para visualizar este mosaico, o QGIS tem de abrir as 45 imagens, ler todos os pixels, e mostrá-los. Ainda por cima, nesta escala a maior parte da informação é inútil porque não se distinguem todos os pixels. Para resolver este problema, criam-se overheads…
Os ficheiro TIFF originais têm 234MB cada um, e para visualizar todos os ortos o QGIS tem de ler todas as imagens, num total de 9GB, e mostrá-las numa escala onde o todo pormenor se perde. Este problema aplica-se a todos os programas SIG, incluindo o MapServer.
Para evitar este desperdício de tempo, criam-se overheads ou pirâmides, que são imagens de resolução decrescente gravadas num só ficheiro com extensão OVR. Assim, para uma escala pequena, como a do exemplo anterior, o QGIS tem apenas de ler e mostrar a imagem de pior resolução, já que se ajusta bem ao pormenor visível a essa escala. Consoante o utilizador faz “zoom in”, o QGIS selecciona a imagem com a resolução apropriada a essa escala, até que a partir de uma dada escala começa a mostrar a imagem original. Mas neste momento já só é necessário ler uma pequena porção da imagem para cobrir a área visível. E assim se acelera a visualização das imagens.
Para criar overheads usamos o comando do GDAL, gdaladdo:
gdaladdo -ro <ficheiro_de_imagem> 2 4 8 16 32 64 128O parâmetro “-ro” indica que a imagem original não deve ser alterada, e portanto as overheads serão criadas num ficheiro separado, que terá a extensão OVR.
Os números depois do nome da imagem são os níveis a criar com resolução reduzida. O n.º 2 indica metade da resolução original, 4 é 1/4 e assim sucessivamente. Até que nível de redução calculamos depende da extensão geográfica das imagens e da sua resolução original. Uma forma fácil de determinar até que redução devemos chegar é consultar o QGIS…
O QGIS consegue agora criar overheads – acedendo às propriedades de um tema de imagem, na secção de Pyramids existe um botão para criar pirâmides (embora seja mais lento que o comando GDAL). Aqui o QGIS mostra a lista de resoluções que aconselha – é só contar quantos níveis são aconselhados pelo QGIS. Na imagem seguinte, podemos ver o QGIS a criar pirâmides para uma das imagens:
Construir pirâmides/overheads no Quantum GIS 1.4.0.
Como o QGIS indicava 7 níveis de pirâmides para as minhas imagens, foi o que usei no comando: 2, 4, 8, 16, 32, 64, 128 = 7 níveis.
Criei então overheads para o mosaico VRT. O resultado foi um ficheiro OVR com 776MB, ou seja, 33% do tamanho original. Esta é a taxa comum na criação de overheads e temos de prever este consumo adicional de disco.
Para testar as overheads, carreguei de novo o mosaico VRT no QGIS. Agora a imagem total foi mostrada quase instantaneamente. Mas ao fazer zoom in a velocidade degradou-se. Significa que o QGIS deixa de usar as pirâmides do VRT e passa a mostrar as imagens originais… penso que poderá ser um bug.
Portanto a solução passa por criar overheads para cada uma das imagens originais, e ver se assim o QGIS utiliza sempre as overheads.
Para isso usei um comando de linha que percorre todas as imagens TIFF numa directoria e executa o comando gdaladdo:
for %I in (directoria_originais\*.tif) do gdaladdo -ro %I 2 4 8 16 32 64 128O resultado foi a criação de um ficheiro OVR para cada TIFF, cada um com 82MB (35% dos originais). Voltando a carregar o mosaico VRT no QGIS, o desempenho foi excelente em todos os níveis de zoom, provando que o QGIS usou sempre as overheads.
NOTA: por curiosidade abri o mosaico VRT no ArcGIS, e tudo funcionou perfeitamente, incluindo as overheads! Sabe-se há muito que o ArcGIS incluía o GDAL, não se sabendo bem para o quê. Pelos vistos, servirá também para ler VRT’s e overheads.
O formato ECW agrada-me muito. Tem compressões equivalentes ao MrSID, é gratuito para comprimir imagens até 500MB, é rápido a visualizar, e já inclui pirâmides no próprio ficheiro. Poupa assim espaço em disco 2x: na compressão e nas pirâmides.
A questão que se coloca é saber até que ponto vai a penalização na performance do MapServer ao ter que descomprimir os ECW para os visualizar a cada Zoom e a cada Pan.
Para criar um mosaico VRT com ECW’s tivemos de converter todos os TIFF originais, com o seguinte comando:
for %I in (directoria_originais\*.tif) do gdal_translate -of ECW -co TARGET=90 %I directoria_destino\%~nI.ecwAs imagens originais passaram de 13GB (contando com as overheads) para 605MB – poupando 95% do espaço! Podiamos ainda comprimir mais, mas neste estudo preferi manter os defaults…
Criámos um novo VRT com as imagens ECW, e testámos no QGIS. A visualização foi muito rápida e sem degradação ao aumentar a escala.
Este formato é muito apreciado por ser familiar, bastante rápido, e apresentar taxas de compressão bastante atractivas (embora não consiga acompanhar a compressão dos novos formatos como MrSID e ECW). A questão que se coloca é saber se a multa devida pela descompressão se nota ou não em MapServer. Não esquecer que será necessário criar overheads. Neste teste optei por criar as pirâmides também em formato JPEG, por forma a ser mais fiel ao formato. Se este formato for suficientemente rápido poderá ser uma boa alternativa ao TIFF. Para criar pirâmides em formato JPEG pode-se usar o seguinte comando (está tudo documentado na página do gdaladdo):
gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL imagem 2 4 8 16 32 64 128O resultado foram imagens JPEG e OVR ocupando 915MB (93% de compressão). Em QGIS o resultado foi mais uma vez excelente… visualização rápida de inicio, sem degradação com os zoom in… Além da velocidade, fiquei surpreendido com a compressão atingida e com a óptima qualidade das imagens ao ver todo o mosaico.
Este formato é uma alternativa aos formatos ECW e MrSID, mas mais aberto. No entanto, tem-se revelado sistematicamente lento demais para o poder utilizar a não ser para fins de arquivo.
Decidi mesmo assim inclui-lo no teste. Converti todas as imagens TIFF para JP2, e criei um mosaico VRT. No teste com QGIS, a velocidade foi muito rápida de início, apenas demorando um pouco mais com o aumento da escala de visualização. No entanto, a sua qualidade de imagem ao ver todo o mosaico foi excelente.
A forma tradicional de usar mosaicos no MapServer é criar um shapefile com polígonos que cobrem a área de cada ortofotomapa. Este shapefile é depois referenciado no mapfile em vez do ficheiro VRT.
A questão que se coloca é saber se a utilização de um VRT implica uma redução de performance, quando comparada com a utilização de um shapefile.
Criei por isso mosaicos usando shapefiles, e medi os tempos de visualização em MapServer. Afinal, nem sempre novos métodos se revelam melhores que os antigos. O comando que usei foi o seguinte:
gdaltindex mosaico.shp directoria\*.tifNão descobri forma de visualizar este tipo de mosaico em QGIS…
A última variante de mosaicos conhecida pela humanidade – juntar todas as imagens numa única, e gigante, imagem.
Para criar este mosaico vamos usar a ferramenta gdal_merge, que é um script python incluído no GDAL (pelo menos na versão FWTools). O plano é juntar todos os tiffs originais, criando um novo tiff. Mas nesta altura, o espaço em disco começava a escassear…
Para poupar algum espaço em disco, optei por usar compressão JPEG. Como o ficheiro poderá ser maior que 4GB usei a opção “bigtiff=yes” (por limitações do formato tiff). E como o ficheiro cobrirá uma grande extensão geográfica, para acelerar o acesso a pequenas áreas, usei também a opção “tiled=yes”. Assim, o comando para criar o mosaico foi o seguinte:
gdal_merge -o mosaico.tif -of gtiff -co compress=jpeg -co tiled=yes -co tfw=yes -co bigtiff=yes -v imagens_originais\*.tifIsto produziu um ficheiro com 3,5GB, dada a compressão JPEG dentro do ficheiro TIFF. Confuso? Sucede que o formato TIFF suporta uma variedade de processos de compressão. Um deles é o JPEG. Claro que esta compressão poderá comprometer a velocidade do mosaico, mas não tinha mais espaço em disco para criar um mosaico sem compressão.
O passo seguinte foi criar overheads/pirâmides para este mosaico. Também aqui optei por criar pirâmides comprimidas em JPEG, usando o seguinte comando:
gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL -ro mosaico.tif 2 4 8 16 32 64 128Este comando criou um ficheiro OVR com 320MB, sendo apenas 9% do original devido à compressão usada. No total, a compressão foi de 72%. Nada mau…
Em QGIS este mosaico foi extremamente rápido, mostrando o ficheiro numa fracção de segundo, e zooms e pans foram também muito rápidos. Definitivamente, foi das melhores prestações senão a melhor.
NOTA: seria interessante criar um mosaico enorme ECW, mas não foi possível por causa do limite de 500MB imposto pela licença gratuita do compressor ECW (incluído no GDAL).
Todos os testes foram efectuados num portátil, com Windows 7, 32-bit, 2 GB de memória, e MS4W 2.2.7 (inclui o MapServer 5.0.2). Portanto, podemos esperar melhores resultados num PC ou servidor, onde o disco rígido será em princípio bastante mais rápido. Os testes foram feitos com uma pequena aplicação OpenLayers, que inicia com um mosaico visível em toda a extensão, sendo depois feitos 4 zooms no centro do mapa, manualmente.
Os tempos foram obtidos no log produzido pelo MapServer. Para criar este log, inseriram-se as seguintes linhas no mapfile:
MAP
CONFIG "MS_ERRORFILE" "/ms4w/mapserver.log"
DEBUG 5O mapa foi configurado para gerar imagens em JPEG, através do AGG, usando esta secção no mapfile:
OUTPUTFORMAT
NAME jpg
DRIVER AGG/JPEG
IMAGEMODE RGB
ENDPara definir um layer com um mosaico VRT usou-se a seguinte sintaxe no mapfile, indicando o ficheiro VRT no tag DATA:
LAYER
NAME 'mosaicoTotal_tif'
TYPE RASTER
DUMP true
TEMPLATE fooOnlyForWMSGetFeatureInfo
EXTENT -16500.000000 -83122.641509 4500.000000 -66877.358491
DATA 'mosaicoTotal_tifoverhds.vrt'
METADATA
'ows_title' 'mosaicoTotal_tif'
END
STATUS OFF
TRANSPARENCY 100
PROJECTION
'init=EPSG:27492'
END
ENDNote-se que foram criados vários layers deste tipo, havendo um VRT para cada tipo de imagem: TIFF, ECW, JPG, JP2.
Para os mosaicos baseados em shapefile usou-se a seguinte sintaxe (TILEINDEX e TILEITEM no lugar de DATA):
LAYER NAME 'mosaicoTotalshp_tif' TYPE RASTER DUMP true TEMPLATE fooOnlyForWMSGetFeatureInfo EXTENT -16500.000000 -83122.641509 4500.000000 -66877.358491 TILEINDEX 'mosaicoshp_tif.shp' TILEITEM 'location' METADATA 'ows_title' 'mosaicoTotalshp_tif' END STATUS OFF TRANSPARENCY 100 PROJECTION 'init=EPSG:27492' END END
Usando mosaicos VRT obtiveram-se os seguintes tempos:
| Zoom | TIFF+overhds | ECW | JP2 | JPG | TIFmonolítico |
|---|---|---|---|---|---|
| Inicial | 0.298 | 0.744 | 1.108 | 0.81 | 0.094 |
| Z1 | 0.354 | 0.609 | 3.205 | 0.945 | 0.259 |
| Z2 | 0.419 | 0.761 | 3.173 | 1.018 | 0.291 |
| Z3 | 0.415 | 0.709 | 3.053 | 1 | 0.284 |
| Z4 | 0.65 | 0.658 | 2.533 | 0.966 | 0.276 |
| Totais | 2.136 | 3.481 | 13.072 | 4.739 | 1.204 |
| Espaço disco | 13,5GB | 605MB | 509MB | 915MB | 3,85GB* |
*usando compressão JPEG, e incluindo overheads.
E em gráfico (a última categoria “Totais” representa a soma de todos os zooms, evidenciando os ganhos acumulados nos formatos mais rápidos):
Desempenho de mosaicos VRT em MapServer.
E o vencedor é… o mosaico monolítico, destacadíssimo. Dos mosaicos VRT, o mais rápido foi o mosaico de TIFF’s não comprimidos, como se supunha de início, com o formato ECW em 2º lugar, bastante melhor que o JPEG em 3º. O formato JPEG2000 é completamente desaconselhado.
Usando mosaicos baseados em Shapefile, obtiveram-se os seguintes resultados:
| Zoom | TIFF+overhds | ECW | JP2 | JPG | TIFmonolítico |
|---|---|---|---|---|---|
| Inicial | 0.287 | 2.374 | 4.206 | 2.366 | 0.094 |
| Z1 | 0.337 | 2.355 | 6.121 | 2.355 | 0.259 |
| Z2 | 0.247 | 1.082 | 3.583 | 1.139 | 0.291 |
| Z3 | 0.186 | 0.656 | 3.069 | 0.76 | 0.284 |
| Z4 | 0.176 | 0.657 | 2.412 | 0.926 | 0.276 |
| Totais | 1.233 | 7.124 | 19.391 | 7.546 | 1.204 |
| Espaço disco | 13,5GB | 605MB | 509MB | 915MB | 3,85GB* |
*usando compressão JPEG, e incluindo overheads.
E em gráfico:
Desempenho de mosaicos SHP em MapServer
E o vencedor é… de novo o TIFF monolítico, mas havendo várias alterações. Só o mosaico de TIFF’s não comprimidos melhorou o desempenho em quase 100%, reduzindo de 2,1s para 1,2s. Todos os outros pioraram bastante, por vezes duplicando o tempo de visualização. Não encontrei explicação para esta penalização. O shapefile continha apenas 45 polígonos, sendo difícil acreditar que possa causar tão grande penalização, mesmo considerando que o MapServer tem de determinar quais os polígonos visíveis num momento, determinar as áreas de cada um, e abrir as imagens correspondentes… parece-me pouco trabalho para explicar diferenças de 1,6s como no caso dos ECW… Mas factos são factos.
Se não existirem impedimentos, deverá unir as suas imagens num mosaico único, em formato TIFF, comprimido em JPEG, e criar pirâmides também com compressão JPEG. Obtém o maior desempenho possível e com o extra de poupar 70% do espaço em disco. Esta abordagem foi simplesmente a melhor… mais vale guardar os seus originais num arquivo.
Quanto aos mosaicos VRT mostraram ser uma boa opção. Quase todos os formatos tiveram melhor desempenho quando usados através deste formato virtual, do que usando um mosaico baseado em shapefile. A excepção foi o mosaico de TIFF’s não comprimidos. Aqui, usar o mosaico shapefile foi melhor, muito melhor.
O formato VRT não serve apenas para criar mosaicos sem alterar as imagens originais, e por isso poderá ser uma opção atractiva em certas situações. Podemos, por exemplo, definir uma deslocação de +200km, +300km sem andar a editar ficheiros de coordenadas – alguém se lembra de passar por isto?? Parece-me que sim.
Todos os comandos usados no artigo…
| Criar mosaico VRT a com imagens de uma directoria: |
|---|
| gdalbuildvrt mosaico_tif.vrt directoria\*.tif |
| Criar overheads/pirâmides de uma imagem, num ficheiro separado |
| gdaladdo -ro imagem.tif 2 4 8 16 32 64 128 |
| Criar overheads/pirâmides para todas as imagens TIFF numa directoria |
| for %I in (directoria_originais\*.tif) do gdaladdo -ro %I 2 4 8 16 32 64 128 |
| Converter todos os TIFF numa directoria para ECW noutra directoria |
| for %I in (directoria_originais\*.tif) do gdal_translate -of ECW -co TARGET=90 %I directoria_destino\%~nI.ecw |
| Criar overheads/pirâmides com compressão JPEG |
| gdaladdo –config COMPRESS_OVERVIEW JPEG –config PHOTOMETRIC_OVERVIEW YCBCR –config INTERLEAVE_OVERVIEW PIXEL imagem.tif 2 4 8 16 32 64 128 |
| Criar mosaico baseado em shapefile das imagens TIFF numa directoria |
| gdaltindex mosaico.shp directoria\*.tif |
| Criar um mosaico monolítico tif, com compressão jpeg, das imagens tiff numa directoria |
| gdal_merge -o mosaico.tif -of gtiff -co compress=jpeg -co tiled=yes -co tfw=yes -co bigtiff=yes -v imagens_originais\*.tif |
| MapServer: configurar um mapfile para gerar um ficheiro log com tempos |
| MAP CONFIG “MS_ERRORFILE” “/ms4w/mapserver.log” DEBUG 5 |
Num cenário de catástrofe juntam-se esforços com o intuito de ajudar os mais necessitados.
Quando estamos perante diferentes sistemas que precisam de interagir é imperativo preconizar a interoperabilidade e fomentar a partilha de informação entre todos, de modo ao esforço envolvido ser o mais eficiente possível.
Um bom exemplo do cenário acima, encontra-se descrito no link abaixo que exemplifica como aceder a dados de OpenStreetMap usando software ArcGIS, de modo a dar uma resposta mais efectiva ao auxílio no pós terramoto do Haiti.
Adriano Hantequeste Gomes (BR)
Ambientes Geográficos
Blog IDEE (ES)
Blog de Geomática (BR)
Blog do Patto (BR)
Cartotech Brasil
Edmar Moretti (BR)
Eloi Ribeiro
Fernando Quadro (BR)
GIS & Chips (ES)
GISVM
Geo para Linux (BR)
GeoPoetas
Geoinformação on-line
Geomatic Blog (ES)
Georden
Geospatial Free Open Source Software (PT)
Luis Carlos Madeira
Luís Sadeck (BR)
Notícias gvSIG (ES)
Sandro Batista
Sextante GIS (ES)
ViaSIG
iDEA Plus (BR)
