Este Sábado acontece um evento muito especial em Vila Nova da Barquinha: GeoCamp. Uma desconferência sobre SIG e outros assuntos tão (quase) interessantes 😉
Pensem nisso – ao mesmo tempo de convivem aprendem. As inscrições são gratuitas. E se quiserem falar, força! (como dizia o outro na rádio – “queres falar?“)
“O GeoCamp é uma “desconferência”, muito inspirada no conceito de Barcamp, que consiste num encontro aberto a todos e conduzido pelos próprios participantes.”
Mais info: GeoCamp.
Nota: Este artigo foi publicado originalmente no último iGov DOC, sobre SIG na Administração Pública, páginas 21-23. Resisti à tentação de fazer alterações que agora me parecem óbvias, e apenas corrigi algumas gralhas. (Aqui no blog fica pesquisável na web…)
Como gestor de um Sistema de Informação Geográfica (SIG) tenho especial interesse em analisar a decisão de usar um dado produto num projecto. E em especial quando esse produto pode ser de Código Aberto (CA) quais são as implicações associadas a essa escolha? Além das minhas próprias escolhas, observo com interesse as escolhas de colegas em situações semelhantes, as suas dúvidas e receios. Em geral, a escolha de produtos CA carregam um receio que não surge na escolha de produtos de Código Fechado (CF). É sobre esta questão que espero contribuir construtivamente neste artigo.
Ler artigo completo
A cidade de Beja há um ano atrás não tinha quase presença no OpenStreetMap. Hoje deve ser uma das cidades mais completas… (é verdade que também é das mais pequenas, mas isso agora não interessa nada!)
Só uma nota rápida para quem não conhece, e fico sempre surpreendido com a quantidade de pessoas que me vão dizendo que não conhecem, o OSM é um projecto internacional, comunitário, de levantamento de dados cartográficos por hobbyistas (chamados pomposamente de voluntários). E tem sido um fenómeno enorme de popularidade, e vale muito a pena investigar. Até porque a sua qualidade é tal que é usado em vários produtos para navegação pessoal. Um dos últimos convertidos é a MapQuest – faça uma visita se quiser ficar impressionado. O OSM começou por levantar a rede rodoviária, e abrange hoje uma série de outras categorias de dados, especialmente pontos de interesse. Mas fiquemos por aqui sobre o projecto OSM em si.
Ler artigo completo
Os ficheiros CAD são uma das principais fontes de dados para um SIG. Este artigo analisa as possibilidades actuais de lidar com CAD no Quantum GIS.
Existe uma rivalidade antiga entre quem trabalha com software CAD e quem trabalha com software SIG – é comum ouvirmos dizer coisas como “o CAD é menos avançado”, ou “os tipos do SIG têm a mania de complicar as coisas”, entre outros mimos. Na realidade CAD e SIG são ferramentas usadas para fazer coisas diferentes, com métodos de trabalho diferentes, e que (infelizmente) têm de conviver de forma muito próxima, sem se compreenderem muito bem… (Aviso: tentei ser isento, mas acho que desisti a meio do texto…)
No CAD esta afirmação é verdadeira. No SIG não.
No CAD eu desenho os meus elementos gráficos com o objectivo principal de obter uma visualização – para ver no monitor ou para imprimir. Quanto mais produtivo for a criar a minha visualização melhor técnico CAD serei. Os elementos que crio no ficheiro CAD representam exactamente o que preciso de ver: uma árvore é constituída por uma copa, um poste de iluminação tem um pé e uma lâmpada, uma área ajardinada tem vários pequenos arbustos. Eu posso seleccionar cada um destes elementos e alterá-los para obter a visualização exacta que pretendo. Quando gravo um DWG ou um DGN gravo tudo isto – uma linha com dada cor, espessura, tipo de tracejado – gravo no ficheiro as geometrias que são também a simbologia em simultâneo. A estrutura do meu desenho é constituída pela forma como eu organizo os meus elementos por camadas (layers ou levels), e como crio os meus elementos (blocos ou elementos simples).
No SIG a situação é muito, muito semelhante. Mas 2 ligeiras diferenças são suficientes para tornar o diálogo entre as equipas CAD e SIG difícil e por vezes até antagónico.
1) No SIG eu desenho apenas geometrias. Recolho vértices XY. E recolho características das geometrias, que armazeno em atributos. Todas as geometrias que recolho num ficheiro têm sempre os mesmos atributos, e por isso descrevo-as de forma sistemática, formando uma tabela. Não há simbologia envolvida no processo. Ao gravar o trabalho num ficheiro de dados, guardo apenas vértices XY e atributos, sendo uma das razões por que grande parte do trabalho é focada em organizar informação, em decidir que atributos cada ficheiro terá. Mas esta obsessão organizativa vai mais longe! Cada ficheiro tem apenas um tipo de geometria – ponto, linha ou polígono – que nunca se misturam no mesmo ficheiro.
2) No SIG a simbologia é aplicada por regras a um ficheiro – não se define a simbologia de um só elemento. Usam-se os atributos para seleccionar um conjunto de geometrias a que depois aplicamos uma certa simbologia. Por exemplo, podemos representar especificamente as cidades com população maior que 1 milhão de habitantes como círculos pretos, as restantes cidades com um quadrado. Se todos os pontos que são as cidades tiverem um atributo com a sua população, o software SIG aplica esta simbologia facilmente. Uma consequência desta abordagem à simbologia é que passa a ser dinâmica. Se quisermos alterar a simbologia, não alteramos as geometrias – alteramos as regras da simbologia. Para guardar a simbologia usam-se ficheiros de projecto, que não têm dados, apenas regras e definições de como representar a informação e como a imprimir (formato da página, orientação, seta do norte, título, ou seja, o layout).
![cad_carto_thumb[1]](/wp-content/uploads/2010/07/cad_carto.png "cad_carto_thumb[1]") |
![sig_carto_thumb[1]](/wp-content/uploads/2010/07/sig_carto.png "sig_carto_thumb[1]") |
| CAD | SIG |
Exemplo de informação CAD original, e quando convertida para SIG.
Como dizem os políticos, ainda bem que fez essa pergunta…
Pois é, o problema é na conversão de CAD para SIG. Este é um assunto muito extenso e interessante, mas como é Verão apetece mais uma bejeca… 🙂 Mas ainda consigo lembrar-me de 3 grandes problemas nesta conversão:
1) Seleccionar num ficheiro CAD elementos que têm o mesmo significado é geralmente difícil. Se todos pontos que são as cidades estiverem num único layer, e nesse layer não existir outro tipo de pontos, então a sua selecção é facílima. Mas isso raramente acontece… geralmente elementos gráficos com diferentes significados coexistem no mesmo layer.
2) Determinar a posição correcta de um elemento é muitas vezes difícil – a cidade está no ponto de inserção do bloco, ou é o ponto central do bloco? O ponto cotado é o ponto de inserção, ou é a virgula decimal do texto da cota? E aqui junta-se a dificuldade de evitar as tramas ou “hatches”. (As tramas são linhas que representam simbologia mas não representam uma entidade no terreno. Geralmente aplicadas a polígonos, servem de arranjo gráfico, e não devem ser convertidas para SIG.) Outro exemplo são marcas quilométricas em eixos de infra-estruturas… no CAD são importantes, no SIG são considerados erros de conversão. Outro grupo de problemas pode ser aqui incluído – questões como converter linhas fechadas do CAD para polígonos no SIG, reconhecer vazios, e outras questões semelhantes…
3) E finalmente, recolher atributos juntamente com as geometrias é muitas vezes… … … difícil (novamente)! e para o SIG os atributos são fundamentais. Por exemplo, qual é a cota de cada ponto cotado ou curva de nível? Ou qual é o nome de cada eixo de rua? A verdade é que já foi feito o trabalho de recolha e digitalização desta informação pela equipa CAD, mas mesmo assim não é possível muitas vezes usá-la num SIG (ou noutro sistema qualquer). No CAD, o texto que mostra o nome de uma rua é uma entidade gráfica independente da linha, e por isso não existem métodos automáticos fiáveis para associar cada linha a cada texto. A não ser que se crie o ficheiro CAD já com a preocupação de permitir este tipo de interoperabilidade, e assim avançamos para tópicos de CAD avançados que (na minha experiência) escapam à maioria dos desenhadores.
Pois é… agora estamos todos numa grande alhada. Ao fim de dias a tentar converter ficheiros CAD, o pessoal do SIG está pronto a abraçar uma vida de crime, começando por cometer uma série de homicídios lá para as bandas do CAD.
A única solução é conhecer bem o software que usamos. Com o tempo vamos aprendendo as técnicas que o software suporta para conseguir conversões cada vez mais automáticas. Mas tudo depende dos ficheiros originais CAD. E é muito importante poder contar com alguém no “lado” CAD que possa alterar os ficheiros CAD de forma a facilitar o processo de conversão.
Outra via de facilitar a vida a todos os técnicos envolvidos num processo que passe por CAD e SIG, é estabelecer regras para os ficheiros CAD que facilitem depois um processo menos manual de conversão. E isso novamente vai depender da informação em causa, e do tipo de AutoCAD em uso (“normal”, Map, Civil…). Por exemplo, no AutoCAD Map podemos criar Object Data, Object Class, ou até ligar os nossos elementos gráficos a tabelas de atributos externos, mas em AutoCAD “simples” isso já não é possível…
Portanto, não há regras infalíveis. Cada caso é um caso, como se diz. Mas há regras de bom senso que resultam sempre bem – agrupar elementos gráficos com o mesmo significado num só layer é uma dessas regras: só eixos de via num layer, e todos os eixos de via estão nesse layer (não há outros tantos eixos noutros tantos layers); cada layer tem um nome claro e intuitivo (nada de layers com nomes do tipo “ev_de” – que quereria dizer “eixos de via do distrito de évora”…); para layers de polígonos criar também o respectivo layer de anotação ou blocos de atributos (onde também marcamos os vazios), e outras regras deste género. Bom senso é muito subestimado hoje em dia…
E finalmente chegamos à parte principal do artigo, que originou o seu nome…
O QGIS usa como leitor de dados as bibliotecas do GDAL (imagens) e OGR (vectores). Este facto não é muito visível para o utilizador, mas é importante para compreender as capacidades do QGIS. Estas bibliotecas têm drivers que são responsáveis por cada formato que o GDAL/OGR suporta. No caso de ficheiros CAD só 2 formatos são suportados – DXF e DGN. Está já pronto um novo driver para DXF e que lê também DWG, mas ainda não é incluído no QGIS (nem mesmo na versão 1.5 a lançar já em Julho).
O OGR converte DXF para qualquer outro formato que suporte, como o shapefile. E mantém alguns atributos, como o layer, o que é muitas vezes suficiente para converter e organizar a informação CAD. Mas enquanto o QGIS não usar uma versão de OGR que inclua o driver DXF não vamos conseguir ler estes ficheiros directamente no QGIS. Temos assim de usar comandos de linha…
Assim, para evitar usar a linha de comandos do OGR, podemos fazer esta conversão no QGIS usando o plugin Dxf2Shapefile (incluído na instalação do QGIS). Mas surpreendentemente este plugin não mantém quaisquer atributos quando converte ficheiros DXF, e ficamos com pontos, linhas e polígonos sem sabermos o que representam. O que é muito desapontante. A sua utilização é muito fácil, mas os resultados são pobres dada a flagrante ausência de atributos.
Conversão de DXF para Shapefile no QGIS – perdem-se os atributos.
Há uma outra opção – o QGIS lê directamente ficheiros DGN, e carrega-os para o mapa sem ser necessário uma conversão prévia. E melhor ainda, vários atributos são visíveis, e assim, tendo o ficheiro CAD no nosso mapa, podemos aplicar selecções de acordo com o level (equivalente ao layer dos DXF), e gravar para ficheiros shapefile.
O QGIS consegue ler DGN directamente e mantém atributos como o level, permitindo fazer selecções e gravar para shapefile.
Uma surpresa é que o DGN é carregado com todas as geometrias misturadas num só tema. O que é invulgar. Temos de nos habituar a esta ideia e encontrar forma de filtrar cada tipo de geometria para as conseguirmos separar e exportar para shapefile. Isto é, vamos criar um filtro (Query) no QGIS para ficar apenas com pontos, e exportá-los para um shapefile. E fazemos o mesmo depois para isolarmos as linhas e os polígonos.
Como o QGIS usa o OGR para ler ficheiros DGN, basta uma consulta à página do driver DGN do OGR, para ficarmos a saber quais os atributos a que temos acesso com ficheiros DGN. E vemos que o atributo “Type” indica o tipo de geometria:
Line (3): Line geometry.
Line String (4): Multi segment line geometry.
Curve (11): Approximated as a line geometry.
B-Spline (21): Treated (inaccurately) as a line geometry.
Arc (16): Approximated as a line geometry.
Ellipse (15): Approximated as a line geometry.
Shape (6): Polygon geometry.
Text (17): Treated as a point geometry.
Ou seja, para no QGIS seleccionar todas as linhas num DGN, podemos usar a seguinte query (usando a opção “Query” no menu de contexto do tema DGN, acedido clicando com o botão direito sobre o tema DGN):
Type = 3 OR Type = 4 OR Type=11 OR Type = 21 OR Type = 16 OR Type = 15
No QGIS filtramos o DGN com uma query, para isolar um só tipo de geometria (ponto, linha ou polígono).
Depois de fazer a query todos os elementos que restam visíveis no QGIS serão linhas, e podem ser gravados para um shapefile usando a opção “Save as” do menu de contexto do tema.
Depois de termos a informação dividida por 3 shapefiles, um por tipo de geometria, podemos então fazer selecções por level para tentar isolar objectos com determinados significados.
Na verdade nem é preciso exportar para shapefile. Podemos simplesmente carregar o ficheiro DGN, filtrar as geometrias, e aplicar depois a simbologia que queremos. Será necessário converter quando, por exemplo, quisermos converter uma série de ficheiros DGN num único shapefile com toda a informação (ou para outro formato como PostGIS ou SpatiaLite).
Este é o pior formato de informação geográfica do mundo. Ponto.
Além de ser alterado a cada 3 anos, é completamente fechado, isto é, para poder ler e escrever este formato é necessário pagar a terceiros, como a Autodesk ou a Open Design Alliance. A propósito da ODA e da má fama do DWG, podem ler esta novela espantosa relatada pelo 1º presidente desta ilustre fundação. Mas pode ser que as coisas estejam a mudar. Recentemente, a ODA chegou a acordo com a Autodesk e lá resolveram as disputas sobre marcas comerciais, e por coincidência (ou não) em Junho publicaram as especificações actualizadas que desenvolveram para ler e escrever DWG. É melhor aproveitar e fazer o download, não vá a situação alterar-se… Estas especificações têm sido insuficientes para criar programas que consigam escrever ficheiros DWG válidos, mas pelo menos para ler estes ficheiros já foram suficientes. Esta nova actualização não sei se virá alterar esta situação, mas terá nova informação sobre o formato DWG 2010…
Não vou alongar-me mais sobre o formato, interessa apenas frisar que até agora o software Open Source teve de criar bibliotecas para ler (ou escrever) ficheiros DWG fazendo um enorme esforço de “reverse engineering”. Que além de ser um trabalho muito pouco interessante, tem de ser revisto a cada 3 anos.
Assim, o QGIS não lê DWG. É possível que o venha a fazer no futuro próximo, havendo avanços no OGR nesse sentido. A ver vamos…
Mesmo a terminar este assunto, tenho de referir que o gvSIG lê DWG até à versão 2004…
Dadas as dificuldades actuais de interoperabilidade do formato DWG, este não é viável de momento com QGIS.
A opção DGN é muitíssimo funcional, e até muito fácil de trabalhar no QGIS. Para utilizadores de Microstation é óptimo. Para utilizadores de AutoCAD há a possibilidade de exportar para DGN a partir do AutoCAD 2008. Para os outros produtos baseados em DWG/DXF já não se pode dizer o mesmo.
Finalmente, o formato DXF é de momento uma má opção, a não ser que façamos a conversão pela linha de comando do OGR para shapefile ou semelhante. Mas espera-se em breve ter no QGIS um suporte ao nível do DGN. Mesmo assim, também obriga à exportação para DXF (a partir do formato CAD nativo), sendo um passo extra que é mais uma pedra na engrenagem para os técnicos CAD.
Se souberem de outras possibilidades aproveitem a secção de comentários.
Até breve.
Update 3 (2022/01/04): novos dados para Portugal Continental aqui: Altimetria Portugal 25m.
Update 2 (2021/07/20): bom, este artigo parece ainda ser pesquisado online. O link atualizado para obter o 7z é este: https://1drv.ms/u/s!AptRQTEJtPHPgRkNn9-q_uNRSMnG?e=z6NuTj. De qualquer forma, parece-me melhor obter o mdt da EEA indicado nos comentários.
Update: adicionei um comentário (1/6/2010) sobre a qualidade deste MDT, avaliada pelo Prof. José Alberto Gonçalves.
Em Junho do ano passado (2009), falei neste artigo sobre o modelo digital do terreno global disponibilizado online e gratuitamente pelos EUA e Japão. Na altura terminei o texto com a esperança de que algum voluntário se oferecesse para obter os dados para Portugal, os processar e disponibilizar à comunidade. Hoje, conheço apenas a iniciativa da ESRI Portugal, que fez estes passos e disponibilizou o MDT aos seus utilizadores através do ArcGIS Online, permitindo o download dos dados já processados ou a sua utilização no ArcGIS de forma remota. O acesso remoto inclui até acesso via WMS, permitindo assim o acesso por utilizadores de outro software (não-ESRI). O endereço WMS pode ser consultado na lista de servidores nacionais WMS do grupo OSGeo-PT. Basta fazer copy/paste para um programa como o QGIS ou o gvSIG para utilizar este MDT. Mais informação sobre o serviço e todas as formas de lhe aceder pode ser consultada no ArcGIS Online.
Mas para os utilizadores que preferem fazer o download dos dados, a solução da ESRI não é tão universal, já que o formato dos dados permite apenas a sua utilização em ArcGIS – isto porque o mdt é disponibilizado numa File Geodatabase.
Assim, pensei em fazer esse pequeno trabalho, e peguei no mdt que tinha tratado na altura, e coloquei-o online. Os passos que fiz foram estes:
Pode assim obter o mdt de 30m para Portugal acedendo a esta página e clicando na opção “Transferir”. Continuar a lerMDT 30m para Portugal
No espírito do Natal deste ano pensei em partilhar as prendas do Ordenance Survey (IGP inglês) ao mundo, que acabou de publicar o documento com a política que seguirá quanto à disseminação dos seus dados. E no capítulo 7, “Release of free products”, lista os produtos que serão gratuitos a partir de 1 de Abril de 2010, e que incluem dados imagem 10k e 25k, e vector, que incluem os códigos postais e a rede viária!
Portanto é caso para dizer, em Inglês claro, OhOhOh Merry Christmas!
Update – links em falta:
documento do OS referido acima: Policy options for geographic information from Ordnance Survey.
mais info: artigo no Mapperz.
Esta é a parte 3 desta série, sobre a utilização de PostGIS com ArcGIS, que aborda a estruturação da bd PostGIS. Os artigos anteriores são:
Depois de instalar o PostgreSQL+PostGIS+ArcSDE, e configurar o formato de armazenar os nossos dados na bd, para que usemos as geometrias nativas do Pg em vez dos objectos ESRI (para compatibilidade com software Open Source), teremos de definir que utilizadores vamos criar na bd, e a forma como organizamos os dados.
A organização interna do PostgreSQL é algo semelhante à do SQL Server, e bastante diferente do Oracle. Por exemplo, um servidor PostgreSQL contém várias bases de dados, ao contrário do Oracle onde uma bd corresponde a um serviço ou instância. Se quisermos mais bd’s temos de criar novas instâncias, com configuração independente, conexões, dados, utilizadores, etc.
Durante a instalação do PostGIS é instalada uma bd chamada “postgis”, e podemos usá-la para armazenar os nossos dados geográficos ou podemos criar outras bd’s ao nosso gosto…
Podemos assim guardar a informação geográfica na base de dados postgis que é criada durante a instalação do PostGIS. Ultrapassada esta decisão, temos de criar e configurar os utilizadores que vamos usar para carregar a nossa informação, evitando usar os utilizadores de sistema, criados durante a instalação, que são o “postgres” e o “sde” (utilizador criado pela instalação do ArcSDE e que serve para efectuar a sua gestão). A criação de novos utilizadores é muito recomendado e geralmente é omitido nos tutoriais e instruções de instalação…
Pessoalmente, prefiro configurações com poucos utilizadores, criando apenas 1 login para cada uso: os utilizadores do SIG usam o mesmo login para a visualização, e um outro para a gestão dos dados (criação, edição, eliminação de layers, metadados, etc.). Aplicações webgis podem partilhar também um único login para acesso aos dados. A abordagem oposta é a de criar um login por utilizador, ou usar a autenticação integrada do Windows (em que as contas de utilizador de domínio são também usadas na bd). Esta é uma decisão que se repercutirá mais tarde na manutenção e monitorização da actividade da bd. Se começarmos com a abordagem mais simples (poucos logins), podemos mais tarde introduzir o esquema de autenticação por utilizador do SIG.
Uma das razões apontada para usar o esquema de mais utilizadores, é que podemos controlar exactamente quem está ligado, ou mesmo até saber quem editou os dados numa dada altura. E esta é uma argumentação válida. Mas a abordagem mais simplista, de poucos logins, também permite algum controlo, uma vez podemos ver no servidor a listagem de conexões activas, e estas são descritas não só pelo login usado, mas também pelo nome da máquina de onde são efectuadas. Como em geral, uma máquina pertence a um utilizador, acabamos por saber que utilizador “real” está efectivamente ligado à bd.
Outra questão a considerar é a de quantos “schemas” serão criados na bd. Um schema é um agrupamento de objectos na bd ao qual se atribui um nome; o nome dos objectos apenas se podem repetir em schemas diferentes. Por exemplo, podemos ter schemas com o nome “Ambiente” com os dados desta temática, ou “Cadastro”, e por aí fora. É preciso sublinhar que podemos controlar quem tem acesso a um schema, podendo proibir o acesso a certos utilizadores, dar acesso apenas de leitura, ou por fim, dar controle completo.
Quando possível, prefiro usar o schema “public” criado de raiz durante a instalação do PgSQL, e não criar mais schemas. Esta abordagem é muito simples, e tem a vantagem de ser a mais compatível com o software que interage com o PostGIS (já aconteceu usar software que não via outros schemas além do public), além de simplificar a gestão de privilégios (o que também pode ser limitativo, caso as nossas necessidades exijam compartilhar os dados por áreas de edição).
Mas sucede que o ArcSDE necessita que todos os utilizadores que criam dados tenham o seu próprio schema. Pelo que a centralização dos dados geográficos no schema public não é possível. Temos de ter tantos schemas quantos os utilizadores que criam dados. Ou seja, se o utilizador João for alguém que tem de criar tabelas novas na bd, então terá de ter obrigatoriamente o seu próprio schema, e com o mesmo nome “João”!
A questão não é complicada se tivermos poucos criadores de dados, porque teremos de criar poucos schemas. Isto não impede que haja muitos editores, que podem editar dados de outros utilizadores e por isso não precisam de ter o seu próprio schema.
Mais info sobre schemas pode ser encontrada na documentação do PgSQL.
Para criar utilizadores no PostgreSQL usamos o PgAdmin (programa de administração) para criar “login roles“. Podemos também criar perfis que no PgSQL são denominados “group roles“, e que permitem gerir conjuntos de utilizadores em simultâneo, que partilham privilégios. O ArcSDE necessita que certas regras sejam seguidas na criação de utilizadores, se quisermos usar o ArcGIS para criar, editar e visualizar os dados.
Em resumo, para criar um novo utilizador que pode criar novos dados através do ArcGIS/ArcSDE, vamos:
i) criar um schema com o mesmo nome do novo utilizador; e
ii) criar um novo login na base de dados postgis, chamado por exemplo “gestorsig”. (Podemos usar o PgAdmin, mas aconselho usar a janela de sql para criar o utilizador.)
O utilizador deverá ter privilégios totais no seu próprio schema, mas também o privilégio de “usage” sobre o schema “sde”, onde são colocadas as tabelas de sistema do ArcSDE. Isto é necessário porque quando o utilizador cria uma nova tabela tem de a registar numa série de tabelas de sistema. Claro que isto é feito automaticamente pelo par ArcSDE/ArcGIS, mas se o utilizador não tiver privilégios não será possível.
Por outro lado, o utilizador “sde” precisa de ter acesso às tabelas criadas, sendo por isso necessário atribuir-lhe o privilégio “usage” sobre o schema do novo utilizador, para que seja capaz de efectuar algumas operações de manutenção (limpeza do versionamento).
E ainda um passo final – como optámos por armazenar os nossos vectores usando o tipo espacial nativo do PostGIS, o nosso utilizador necessita de acesso de escrita à tabela “public.geometry_columns”, onde se registam todas as tabelas espaciais do PostGIS. De outra forma, as nossas tabelas não seriam reconhecidas como tendo geometrias.
Concluindo, para criar um utilizador capaz de criar novas tabelas, usamos o seguinte SQL:
Update (13/06/2010): é também necessário dar pelo menos acesso (SELECT) à tabela de sistemas de coordenadas (spatial_ref_sys).
create role gestorsig login password 'PasswordDoUtilizador' noinherit createdb;
create schema gestorsig authorization gestorsig;
grant usage on schema sde to gestorsig;
grant usage on schema gestorsig to public;
grant select, insert, update, delete on table public.geometry_columns to gestorsig;
grant select on table public.spatial_ref_sys to gestorsig;
Neste código há uma pequena nuance: damos acesso ao nosso schema a todos os outros utilizadores (“…to public”), e assim não nos preocupamos se damos acesso a A ou B.
Para criar um utilizador que edita dados, mas não cria novas tabelas, o processo é quase igual. Apenas não necessita do seu próprio schema (usará o public por default):
create role editorsig login password 'PasswordDoUtilizador';
grant usage on schema sde to editorsig;
grant select, insert, update, delete on table public.geometry_columns TO editorsig;
Nota: como o nosso utilizador que cria dados (gestorsig) deu acesso a todos os utilizadores, não temos de o fazer explicitamente para novos utilizadores.
Nota 2: para podermos editar os dados criados pelo gestorsig, temos de dar privilégios de UPDATE ao nosso editor. Podemos fazê-lo usando o ArcCatalog (selecionar as Feature Classes, e com botão direito usar a opção “Privileges”), ou usando SQL.
No caso de utilizadores que só visualizam dados, o processo é igual. A diferença é que no ArcCatalog apenas damos o privilégio de SELECT sobre os objectos criados.
Deixo aqui 2 links que resumem a forma de criar novos utilizadores:
Todo este processo é muito semelhante ao que se passa com outros SGBDR’s, como Oracle ou SQL Server. Apenas muda a terminologia, e alguma da lógica de compartimentação da estrutura da bd. Para quem vem do mundo Oracle, a adaptação ao PostgreSQL é muito fácil, e para utilizadores de SQL Server não é muito diferente…
Este post é o 2º sobre integrar ArcGIS e PgSQL. A 1ª parte pode ser encontrada aqui.
Este artigo continua a experiência de usar o PgSQL como base de um SIG baseado em ArcSDE/ArcGIS, debruçando-se sobre a instalação e tipo de conexões. Não é uma introdução ao PostgreSQL/PostGIS, e é assumido que o leitor tem algum conhecimento prévio ou que o irá obter noutra fonte… por exemplo aqui:
O instalador do ArcSDE é muito simples, e até inclui o PostgreSQL. Mas se seguirmos o wizard de instalação do ArcSDE, não será instalado o PostGIS e o ArcSDE será instalado no seu modo default, com o seu próprio tipo espacial (coluna de geometria) e o seu próprio SQL espacial. Desta forma, só se consegue aceder aos dados geográficos com software ESRI.
Para instalar o ArcSDE de forma a que os dados sejam armazenados usando o tipo espacial do PostGIS é necessário desviarmo-nos um pouco do caminho seguido pelo wizard de instalação. Quando o wizard acaba de instalar o PostgreSQL, temos de parar, e instalar o PostGIS, antes de prosseguir com o wizard do ArcSDE. Tudo é bem explicado neste artigo da ESRI:
HowTo: Install PostgreSQL 8.3.0, ArcSDE 9.3, and PostGIS 1.3.2 on Windows
No final da instalação ficamos assim com o PostgreSQL, o PostGIS, e o componente ArcSDE.
O componente ArcSDE cria uma base de dados no PostgreSQL, chamada “sde”, e um utilizador próprio chamado “sde”. É nesta bd que ficam as tabelas de sistema do ArcSDE e a suas próprias funções, triggers, etc.
O nosso servidor PostgreSQL fica também com a estrutura habitual do PostGIS, havendo uma bd denominada “postgis”. Nesta bd também são instalados objectos do ArcSDE, como tabelas de configuração da geodatabase que mantém registo dos objectos que são criados através de software ESRI e que compõem o modelo de dados da geodatabase.
Na instalação há um problema com privilégios – a instalação do ArcSDE pára porque não consegue escrever nas directorias do PostgreSQL (“lib” e “bin”). Para resolver basta usar o explorador do Windows para adicionar o privilégio de escrita nessas pastas ao nosso utilizador (que estamos a usar ao executar o instalador do ArcSDE). Se usarmos o utilizador “Administrator” o problema não surge.
Outra nota importante é que o PostgreSQL é instalado com as definições pré-definidas. Sucede que estas definições são à prova de equipamento pré-histórico… ou seja, o PostgreSQL instalado e sem alterações funciona até num Intel 486 com 256MB de memória. Mas claro que a performance não é a desejada e deve-se editar as configurações. Noutro artigo espero discutir um pouco as opções mais comuns a alterar.
A título de curiosidade, os valores default de configuração ocupam cerca de 60MB de memória (sem iniciar o serviço SDE e sem contar com o pg_ctl.exe).
Depois da instalação são criados 2 novos serviços no Windows: o usual do PgSQL, e um próprio do ArcSDE.
O serviço do ArcSDE é o gestor de conexões do ArcSDE. Ou seja, as aplicações da ESRI ligam-se a este serviço, que depois inicia as conexões à base de dados para cada aplicação. A ESRI designa este esquema conexões como “Application Server connections” ou de 3 camadas (3-tier). Cada utilizador de ArcGIS que se liga deste modo vai criar um processo no servidor chamado “gsrvr.exe”, que optimiza a comunicação dos dados entre a bd e o ArcGIS. Cada um destes processos ocupa entre 15MB e 100MB de memória, para além da memória ocupada pelo próprioPgSQL. Se houver 10 postos ArcGIS, serão lançados 10 processos destes no servidor, ocupando 150-1000MB de memória. Isto para além dos processos que o PgSQL irá criar por si.
Nos últimos anos, a ESRI tem vindo a incentivar o uso de outro tipo de conexões – conexões directas.
Nas conexões directas não é necessário usar o serviço ArcSDE, o ArcGIS liga-se directamente à bd. Isto é possível porque o ArcGIS passou a incluir as dll’s do ArcSDE, e assim a memória que era ocupada no servidor passa a ser consumida no PC com o ArcGIS. O inconveniente é que estas conexões ocupam um pouco mais a rede, mas teoricamente não há impacto perceptível. Com as conexões directas apenas temos de contar com os processos do próprio PgSQL.
Naturalmente, desde que a rede não esteja congestionada, é preferível usar conexões directas. No entanto, o esquema de conexões 3-níveis permite separar o ArcSDE da bd, o que possibilita a utilização de clusters, beneficiando da distribuição de carga que este tipo de sistemas oferece.
O PgSQL quando inicia cria um conjunto de 6 processos em memória no servidor. Em Windows, todos estes processos se chamam “postgres.exe”. Um destes processos é o processo principal do servidor que mantém a cache de dados e outras informação que persistem entre conexões. A configuração do PgSQL influenciará principalmente este processo, que tanto pode ocupar 26MB como 500MB, ou mais.
Por cada cliente que se conecta (QGIS, gvSIG, …), o PgSQL cria mais 1 processo na memória do servidor, correspondendo a essa conexão (curiosamente, no caso do ArcGIS são sempre criados 2 processos postgres.exe). Este processo ocupará memória consoante as definições do PgSQL, dependendo fortemente do tipo de operações executadas pelo cliente. Assim, uma pesquisa simples consumirá pouca memória, mas a visualização de um layer com 120.000 registos já ocupará +200MB. O caso de maior carga que encontrei foram operações de carregamento de informação em massa ocupando 500MB de memória ou mais.
Confesso que não estou habituado a esta flutuação no consumo de memória. Ao usar Oracle, temos uma certa rigidez no consumo de memória, que orbitará em redor dos parâmetros determinados pelo gestor. Se o Oracle der sinal de necessitar de mais memória, é o gestor que tem de redefinir os parâmetros permitindo que o Oracle consuma mais memória.
No caso do PgSQL, a memória ocupada é também reflexo da configuração definida pelo gestor, mas a variação da memória ocupada é muitíssimo maior. E varia por cada utilizador que se liga, e pelas operações que irá efectuar. É um dimensionamento mais difícil de manter dentro dos limites do servidor.
Suponho que é uma questão de habituação ao processo. Durante uma fase inicial de implementação será necessário monitorizar de perto a utilização de memória no servidor, e adaptar as configurações do PgSQL. Tal e qual como se passa com outros servidores SGDB. Penso ainda regressar a este assunto, continuando esta série de artigos… até breve.
As 2ªs Jornadas de Software Aberto de Sistemas de Informação Geográfica terminaram, e pensei em escrever um pequeno post sobre o evento.
Em relação à organização, foi consensual – a qualidade do evento foi muito acima da média, mesmo comparando com eventos de muito maior dimensão. O espaço estava bem adaptado e equipado, e o evento social (jantar) foi simplesmente fantástico.
Mas o que mais sobressaiu foi o espírito que se viveu na conferência. Falando com várias pessoas, todas apontavam este sentimento de partilha, entre-ajuda, e camaradagem, como algo de especial, que não se vê noutros congressos. Por isso, aconselho vivamente a quem se interesse pela área dos SIG que assista às próximas SASIG em 2010, que serão em Lisboa (temos de aguardar por mais detalhes).
O facto de termos presentes alguns convidados de fora, envolvidos em projectos de grande projecção, também ajudou e muito a elevar o nível de interesse. Estiveram presentes e fizeram apresentações responsáveis dos projectos World Wind (da NASA), do gvSIG, do Sextante. Também foi muito interessante ouvir as experiências e opiniões de pessoas envolvidas no desenvolvimento de comunidades noutros países, havendo representantes da própria OSGeo internacional, e dos capítulos locais Italiano e Espanhol.
Quanto às apresentações, foi apresentado um bom painel de assuntos, muito abrangente. Das apresentações que vi, apreciei muito 2 apresentações de mestrandos, com excelente nível técnico, o que comprova a qualidade do nosso ensino e dos nossos estudantes. Precisamos de mais casos assim, e pessoalmente gostaria de ver mais comunicações universitárias com tão elevado grau de exigência.
Todas as comunicações estão já disponíveis para download (84MB), e parece que teremos o video também em breve:
http://evora.sigaberto.org/downloads/apresentacoes.zip
Uma apresentação que me chamou a atenção em especial foi a do Sapo Mapas. Este site de mapas aparentemente fez tudo bem: tem cartografia temática de grande qualidade, com uma quantidade impressionante de pontos de interesse (200 mil agora, para breve 600 mil), pesquisa de códigos postais 7 dígitos, itinerários, “trânsito em directo”, fotografias panorâmicas, e ainda uma API que qualquer pessoa e empresa pode usar para incluir mapas no seu próprio site, e totalmente gratuita, mesmo em caso de sites com fins comerciais. A continuar assim, esta é uma grande novidade em Portugal, e penso que o é mesmo a nível mundial. Não conheço outra API que tenha uma licença tão livre, ficando Portugal mais bem servido que todos os outros países. É claro que fica o receio da PT alterar o licenciamento e ficarmos com o nosso site ilegalizado, mas para já o facto é que é gratuita.
A API é muito semelhante à do OpenLayers, pelo que será muito familiar a quem conhece. No site do Sapo Mapas há documentação e exemplos para quem quiser aventurar-se. Mas acho algo penoso que tenham reinventado a API do OpenLayers – podiam ter usado o original.
Foram realizados diversos worshops, ou sessões práticas de 3-4h, sobre diversos programas: gvSIG, OpenLayers, PostgreSQL/PostGIS, Quantum GIS, World Wind, Linux, Sextante, GISVM, e MapServer.
Pretende-se publicar online os materiais de cada workshop (dados e slides), mas para já temos a possibilidade de obter um zip dos dados de cada workshop no site das jornadas aqui:
http://evora.sigaberto.org/?q=node/85
Uma iniciativa que achei interessante foi a de ter sido criada uma distribuição Linux própria para estes workshops, com todo o software pré-instalado. Poderão ter de ainda copiar os dados dos workshops, mas de resto está tudo lá. Podem obter esta distribuição no mesmo link dos workshops.
Se gravarem o ficheiro (iso ou img) para uma pen usb ou para um DVD, podem ligar o computador a partir destes suportes, ficando com uma máquina Linux funcional, sem necessitar de mais instalações de software. Também se quiserem, podem converter estes ficheiros numa máquina virtual, que pode ser usada mesmo em Windows, novamente sem instalações de software (a não ser, claro, o software para utilização de máquinas virtuais – por exemplo o Virtual Box OSE).
Para breve está prometido um local para descarga dos materiais incluindo os slides.
Há uns anos criei um mdt único de 90 m de resolução para a Península Ibérica, que uso desde então em mapas regionais. Este mdt foi criado a partir da SRTM, missão efectuada em 2000 pelo Space Shuttle Endeavour.
Agora, desde ontem 29 de Junho de 2009, foi disponibilizado um novo mdt global de 30m de resolução, criado a partir do satélite ASTER, numa colaboração entre a NASA e o governo japonês. O mdt foi criado a partir de 1,5 milhões de imagens ASTER, recorrendo à sua correlação estereográfica. Os detalhes podem ser consultados aqui: METI and NASA Release ASTER Global DEM.
Há vários locais para obter os dados. Um que experimentei é este: ASTER GDEM search system. É um sistema interactivo em que podemos seleccionar a área de interesse desenhando um polígono. Obtemos uma listagem das quadrículas que nos interessam e fazemos a sua descarga. (por alguma razão o download não correu bem…)
É-nos pedido o registo de utilizador, e que indiquemos o fim a que se destina a informação. Supostamente, obtemos uma licença de utilização limitada a esse fim… este tipo de permissão amputada agasta-me… mais ainda numa informação distribuída gratuitamente. Têm receio que faça o quê com os dados? Enfim…
Depois de obtermos as quadrículas, o melhor será construir um mosaico num único ficheiro, e reprojectar para o sistema de coordenadas que mais usamos – não confirmei mas julgo que o original está em WGS84. O formato também não consegui ainda confirmar, mas em tempos o ASTER produzia ficheiros no formato HDF-EOS, que é um formato algo complicado e pouco comum. Nessa altura, havia alguns programas para a conversão, incluindo os excelentes MicroDEM e 3DEM.
Ou seja, precisamos de um voluntário que obtenha os vários tiles do mdt, os junte num mosaico, e reprojecte num sistema de coordenadas comum em Portugal. E depois, se não for pedir muito, que o disponibilize à comunidade!! Alguém se apresenta?