2. ●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
3. ●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
4.
5.
6.
7.
8.
9. ●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
11. 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”...)
12. 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!!
13. 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
14. 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
15. Nessa direção a SAGE está investindo em um novo produto chamado
GEOSAÚDE
16. 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
17.
18. 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
19. 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
20. 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
21. 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 # CLASS
END # LAYER
22. 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
23. ●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
26. ●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
27. ●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
28. Exemplo de um painel composto de mapa e gráficos
O mapa pode receber operações de zoom e pan
As camadas do mapa podem ser ligadas ou
desligadas
29. O usuário pode também interagir clicando em um
ponto no mapa para obter mais dados
32. Exemplo de uso do i3Geo no desenvolvimento de um
aplicativo com diferentes funcionalidades
33. ●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
35. 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”...)
36. 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!!
37. 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
38. 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
39. Nessa direção a SAGE está investindo em um novo produto chamado
GEOSAÚDE
40. 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
41.
42. 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
43. 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
44. 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
45. 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 # CLASS
END # LAYER
46. 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
47. ●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
