Desafios da integração do software i3Geo com o Pentaho

●A SAGE (Sala de Apoio à Gestão Estratégica) do Ministério da Saúde tem a responsabilidade pela qualificação e divulgação de dados do Ministério

●Praticamente todos os dados possuem uma referência espacial, normalmente municípios, representados quase sempre na forma de polígonos

●Em alguns casos utilizam-se referências que são representadas pontualmente, como os estabelecimentos de saúde

●A SAGE utiliza gráficos, tabelas e mapas interativos para mostrar os dados

●Esses mapas utilizam a API do Google Maps, o i3Geo ou a combinação de ambos. A escolha depende do tipo de dado e das características que se quer valorizar no resultado final

●Quando a opção é pelo GM normalmente as informações são pontuais. Para inclusão nos mapas os dados passam pelo processo de conversão para KML ou então são tratados diretamente em javascript, mas sempre as consultas são obtidas diretamente do banco de dados utilizando-se PHP.

●Quando os mapas fazem parte de uma aplicação, com funcionalidades mais complexas, ou quando é necessário representá-los na forma de polígonos, a opção é o i3Geo

●Considerando-se apenas o i3Geo, atualmente existem mais de camadas configuradas e em condições de uso

●Cada camada contém uma unidade de informação (variável) cujos dados estão em um banco Postgres+Postgis

●A cada camada corresponde um arquivo de configuração que contém o SQL e a legenda (definição das classes e da simbologia)

●Esses arquivos seguem a sintaxe utilizada pelo software Mapserver

●Muitas das variáveis possuem dimensão tempo mas não estão representadas dessa forma, mas isso vai mudar!!!

●Espera-se um crescimento cada vez maior no número de camadas considerando-se o ritmo acelerado das demandas

Exemplo de um arquivo Mapfile:

Afinal, o que é o i3Geo?

●Software livre desenvolvido pelo Ministério do Meio Ambiente e “adotado” pelo Ministério da Saúde

●Integrante do Portal do Software Público Brasileiro (quase que desde o início do Portal)

●Parceiro da Associação gvSIG (software desktop desenvolvido na Espanha e um dos mais usados no mundo)

Para que serve:

●Implementar mapas interativos na internet

●Organizar o conjunto de camadas disponíveis

●Oferecer serviços de acesso aos dados (download, “web services”...)

Quais os grandes desafios que temos no momento na SAGE:

●Estamos em pleno movimento de implantação do Pentaho

●Os processos de trabalho da SAGE estão sendo aprimorados

●Os usuários estão cada vez mais ávidos pelos dados oferecidos (usuários da internet, técnicos, diretores, ministros e presidenta da república...)

●Novos softwares estão sendo testados e implementados (PDI, CCC2, SAIKU, D3JS...)

●Os dados que manipulamos são cada vez mais importantes para os gestores, uma falha pode significar muita dor de cabeça

●Mapas não são mais uma coisa “extra” ou “ilustrativa”

●As pessoas adoram, precisam e querem mapas!!

Problemática (em relação aos mapas)

●A grande quantidade de camadas (mapfiles) dificulta a manutenção dos mapas

●O uso de SQL em cada camada exige muito cuidado pois alterações no banco devem ser refletidas nos diversos arquivos de configuração

●Dados com variações no tempo exigem tratamento especial nas aplicações (para evitar a proliferação de arquivos de configuração)

●Não há um mecanismo adequado para documentar a origem dos dados além de outras características importantes que afetam seu uso (restrições, tipos de unidades de medida, qualidade, etc)

●Os usuários querem softwares mais inteligentes e bacanas para a extração de informações e não apenas bons na visualização

●Ao olhar um mapa o usuário quer também tabelas e gráficos, da mesma forma, os gráficos e tabelas precisam dos mapas para que a análise seja completa

Solucionática

●Aprimorar o i3Geo para que o tratamento de dados estatísticos seja padronizado, facilitando a criação de cartogramas e permitindo a realização de processos analíticos mais avançados

●Fazer com que o Pentaho e o i3Geo se falem para que um aproveite do outro as funcionalidades que lhes são complementares

Nessa direção a SAGE está investindo em um novo produto chamado GEOSAÚDE

Características:

●Totalmente baseado no i3Geo

●Não depende de uma estrutura específica do banco de dados

●Baseia-se em metadados, que servem de ponte entre o banco de dados e a aplicação

●Permite o tratamento de dados temporais

●Realiza automaticamente as agregações dos dados (bairro->município->uf->região...)

●O usuário utiliza um sistema de administração ou “ajudantes” para a construção dos metadados

Como o Geosaúde será oferecido aos municípios brasileiros, foi desenvolvido também um módulo para digitalização. Esse módulo permite a contrução dos limites políticos que serão utilizados para a espacialização dos dados

E o BI?

Aliando a experiência com o uso do i3Geo e do Pentaho, mais o potencial do Geosaúde, queremos agora:

●Visualizar mapas dentro do SAIKU utilizando o i3Geo

●Utilizar o SAIKU para analisar os dados existentes em um mapa, ou seja, abrir o SAIKU a partir do i3Geo

Como fazer isso? Algumas ideias:

●Utilizar a biblioteca GEOJSP e OGR para acessar dados via MDX. Isso permitiria a inclusão de uma query diretamente em um arquivo mapfile, substituindo o SQL

●Utilizar os metadados do Geosaúde para gerar o arquivo XML de configuração de cubos. Isso permitiria que os dados utilizados em uma ou mais camadas de um mapa pudessem ser “entendidos” pelo Mondrian

Exemplo de um mapfile com MDX:

LAYER NAME geojs_ogr1 TYPE point STATUS DEFAULT CONNECTIONTYPE OGR CONNECTION "http://127.0.0.1:8080/geojsp/GenerateGeoJSON?type=3&MDXQuery=SELECT [Age].[6-11] ON COLUMNS '{Filter ([GeospatialDimension.Geo].Children' ([Age].[6-11]) > 40000)}ON ROWS FROM [Refugees]" DATA "OGRGeoJSON" TRANSPARENCY 100 CLASS NAME " " STYLE COLOR 255 255 0 OUTLINECOLOR 0 0 0 SIZE 12 SYMBOL ponto END END # CLASSEND # LAYER

Problemas

●É necessário extrair os dados do banco, converter para GEOJSON e depois renderizar o mapa

●Essa conversão e transporte pode ser bastante ineficiente nos casos de polígonos

●É necessário um serviço que receba o MDX e gere o GEOJSON

Vantagem

●Fácil integração com o BI e com o i3Geo, sem a necessidade de qualquer desenvolvimento adicional

●A segunda opção (uso dos metadados) não foi testada, mas o funcionamento seria mais ou menos dessa forma:

● O usuário adiciona ao mapa uma ou mais camadas

● O usuário escolhe camadas que possuem a mesma agregação geográfica (municípios p.ex)

● O usuário define as colunas desejadas

● O sistema gera o XML no padrão que o Pentaho possa utilizar

Obrigado!

Edmar Moretti

Skype, gmail: edmar.moretti

Desafios da integração do software i3Geo com o Pentaho

●A SAGE (Sala de Apoio à Gestão Estratégica) do Ministério da Saúde tem a responsabilidade pela qualificação e divulgação de dados do Ministério

●Praticamente todos os dados possuem uma referência espacial, normalmente municípios, representados quase sempre na forma de polígonos

●Em alguns casos utilizam-se referências que são representadas pontualmente, como os estabelecimentos de saúde

Os municípios podem ser agregados em regiões de saúde, unidades da federação e outros tipos de regionalizações. Raramente utilizam-se dados em níveis menores, como setores censitários ou bairros

●A SAGE utiliza gráficos, tabelas e mapas interativos para mostrar os dados

●Esses mapas utilizam a API do Google Maps, o i3Geo ou a combinação de ambos. A escolha depende do tipo de dado e das características que se quer valorizar no resultado final

●Quando a opção é pelo GM normalmente as informações são pontuais. Para inclusão nos mapas os dados passam pelo processo de conversão para KML ou então são tratados diretamente em javascript, mas sempre as consultas são obtidas diretamente do banco de dados utilizando-se PHP.

●Quando os mapas fazem parte de uma aplicação, com funcionalidades mais complexas, ou quando é necessário representá-los na forma de polígonos, a opção é o i3Geo

Exemplo de um painel composto de mapa e gráficosO mapa pode receber operações de zoom e panAs camadas do mapa podem ser ligadas ou

desligadas

O usuário pode também interagir clicando em um ponto no mapa para obter mais dados

Exemplo de uso do Google Maps

Exemplo de uso do Google Maps

Exemplo de uso do i3Geo no desenvolvimento de um aplicativo com diferentes funcionalidades

●Considerando-se apenas o i3Geo, atualmente existem mais de camadas configuradas e em condições de uso

●Cada camada contém uma unidade de informação (variável) cujos dados estão em um banco Postgres+Postgis

●A cada camada corresponde um arquivo de configuração que contém o SQL e a legenda (definição das classes e da simbologia)

●Esses arquivos seguem a sintaxe utilizada pelo software Mapserver

●Muitas das variáveis possuem dimensão tempo mas não estão representadas dessa forma, mas isso vai mudar!!!

●Espera-se um crescimento cada vez maior no número de camadas considerando-se o ritmo acelerado das demandas

Exemplo de um arquivo Mapfile:

Afinal, o que é o i3Geo?

●Software livre desenvolvido pelo Ministério do Meio Ambiente e “adotado” pelo Ministério da Saúde

●Integrante do Portal do Software Público Brasileiro (quase que desde o início do Portal)

●Parceiro da Associação gvSIG (software desktop desenvolvido na Espanha e um dos mais usados no mundo)

Para que serve:

●Implementar mapas interativos na internet

●Organizar o conjunto de camadas disponíveis

●Oferecer serviços de acesso aos dados (download, “web services”...)

Quais os grandes desafios que temos no momento na SAGE:

●Estamos em pleno movimento de implantação do Pentaho

●Os processos de trabalho da SAGE estão sendo aprimorados

●Os usuários estão cada vez mais ávidos pelos dados oferecidos (usuários da internet, técnicos, diretores, ministros e presidenta da república...)

●Novos softwares estão sendo testados e implementados (PDI, CCC2, SAIKU, D3JS...)

●Os dados que manipulamos são cada vez mais importantes para os gestores, uma falha pode significar muita dor de cabeça

●Mapas não são mais uma coisa “extra” ou “ilustrativa”

●As pessoas adoram, precisam e querem mapas!!

Problemática (em relação aos mapas)

●A grande quantidade de camadas (mapfiles) dificulta a manutenção dos mapas

●O uso de SQL em cada camada exige muito cuidado pois alterações no banco devem ser refletidas nos diversos arquivos de configuração

●Dados com variações no tempo exigem tratamento especial nas aplicações (para evitar a proliferação de arquivos de configuração)

●Não há um mecanismo adequado para documentar a origem dos dados além de outras características importantes que afetam seu uso (restrições, tipos de unidades de medida, qualidade, etc)

●Os usuários querem softwares mais inteligentes e bacanas para a extração de informações e não apenas bons na visualização

●Ao olhar um mapa o usuário quer também tabelas e gráficos, da mesma forma, os gráficos e tabelas precisam dos mapas para que a análise seja completa

Solucionática

●Aprimorar o i3Geo para que o tratamento de dados estatísticos seja padronizado, facilitando a criação de cartogramas e permitindo a realização de processos analíticos mais avançados

●Fazer com que o Pentaho e o i3Geo se falem para que um aproveite do outro as funcionalidades que lhes são complementares

Nessa direção a SAGE está investindo em um novo produto chamado GEOSAÚDE

Características:

●Totalmente baseado no i3Geo

●Não depende de uma estrutura específica do banco de dados

●Baseia-se em metadados, que servem de ponte entre o banco de dados e a aplicação

●Permite o tratamento de dados temporais

●Realiza automaticamente as agregações dos dados (bairro->município->uf->região...)

●O usuário utiliza um sistema de administração ou “ajudantes” para a construção dos metadados

Como o Geosaúde será oferecido aos municípios brasileiros, foi desenvolvido também um módulo para digitalização. Esse módulo permite a contrução dos limites políticos que serão utilizados para a espacialização dos dados

E o BI?

Aliando a experiência com o uso do i3Geo e do Pentaho, mais o potencial do Geosaúde, queremos agora:

●Visualizar mapas dentro do SAIKU utilizando o i3Geo

●Utilizar o SAIKU para analisar os dados existentes em um mapa, ou seja, abrir o SAIKU a partir do i3Geo

Como fazer isso? Algumas ideias:

●Utilizar a biblioteca GEOJSP e OGR para acessar dados via MDX. Isso permitiria a inclusão de uma query diretamente em um arquivo mapfile, substituindo o SQL

●Utilizar os metadados do Geosaúde para gerar o arquivo XML de configuração de cubos. Isso permitiria que os dados utilizados em uma ou mais camadas de um mapa pudessem ser “entendidos” pelo Mondrian

Exemplo de um mapfile com MDX:

LAYER NAME geojs_ogr1 TYPE point STATUS DEFAULT CONNECTIONTYPE OGR CONNECTION "http://127.0.0.1:8080/geojsp/GenerateGeoJSON?type=3&MDXQuery=SELECT [Age].[6-11] ON COLUMNS '{Filter ([GeospatialDimension.Geo].Children' ([Age].[6-11]) > 40000)}ON ROWS FROM [Refugees]" DATA "OGRGeoJSON" TRANSPARENCY 100 CLASS NAME " " STYLE COLOR 255 255 0 OUTLINECOLOR 0 0 0 SIZE 12 SYMBOL ponto END END # CLASSEND # LAYER

Problemas

●É necessário extrair os dados do banco, converter para GEOJSON e depois renderizar o mapa

●Essa conversão e transporte pode ser bastante ineficiente nos casos de polígonos

●É necessário um serviço que receba o MDX e gere o GEOJSON

Vantagem

●Fácil integração com o BI e com o i3Geo, sem a necessidade de qualquer desenvolvimento adicional

●A segunda opção (uso dos metadados) não foi testada, mas o funcionamento seria mais ou menos dessa forma:

● O usuário adiciona ao mapa uma ou mais camadas

● O usuário escolhe camadas que possuem a mesma agregação geográfica (municípios p.ex)

● O usuário define as colunas desejadas

● O sistema gera o XML no padrão que o Pentaho possa utilizar

Obrigado!

Edmar Moretti

Skype, gmail: edmar.moretti