Arquivo de etiquetas: ArcGIS

Mosaicos com áreas transparentes

Avançado, Open Source, SIG, , , ,
Tempo de leitura: 9 min

Neste artigo regresso a um assunto já familiar neste blog – criar mosaicos de ortofotomapas usando o GDAL – (sim eu sei, outra vez?) mas como tenho andado às voltas com as áreas sem informação, que surgem negras nos mosaicos pensei em postar o que acabei por fazer. A solução final é usar máscaras, e não bandas alfa como habitual. Vamos ver como e porquê… assume-se já alguma familiaridade com o GDAL, mas pode sempre saltar as partes teóricas aborrecidas e ver os comandos usados no final do artigo 😉 Ler artigo completo

PostgreSQL e ESRI – parte 4

Avançado, Open Source, PostgreSQL, , ,
Tempo de leitura: 6 min

O subtítulo deste artigo devia ser “O bom, o mau e o péssimo”…

Depois de ter respondido a um comentário que me perguntava sobre a nossa experiência em curso de migrar para PostgreSQL, pensei em melhorar a resposta e fazer um artigo – a maior parte da escrita já estava feita de qualquer forma 😉

Responder ao comentário levou-me a pensar mais um pouco sobre a questão… e uma parte que me parecia pouco clara é o porquê de fazermos a migração para PostgreSQL (pgsql prós amigos) e porquê insistir em usar geometrias PostGIS (geometrias pg)? Só para recordar: a ESRI permite 2 formatos de armazenamento das geometrias nas bases de dados que suporta – ou no formato ESRI (que chamou de ST_Geometry) ou no formato “nativo” da bd.
Ler artigo completo

PostgreSQL e ESRI – parte 3

Dados, Gestão, Intermédio, Open Source, PostgreSQL, SIG, , ,
Tempo de leitura: 5 min

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.

Bases de Dados e Utilizadores

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.

Utilizadores e Schemas

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.

Criar Utilizadores

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…

PostgreSQL e ESRI – Parte 1

Gestão, Inicial, Open Source, SIG, ,
Tempo de leitura: 7 min

A atracção do software Open Source é também sentida pelos utilizadores ESRI. Numa discussão na web li uma vez alguém descrever um utilizador de ArcGIS da seguinte maneira: “a única forma de retirar o ArcGIS das mãos de um utilizador é arrancá-lo das suas mãos mortas e frias”… a crer nisto, no lado de aplicações SIG desktop não será fácil substituir o ArcGIS por qualquer outra alternativa.

Será no entanto mais fácil explorar alternativas para os componentes que se encaixam na área dos servidores SIG, ou seja, bases de dados espaciais e servidores webGIS. Um dos produtos Open Source que tem recebido muita atenção na comunidade ESRI é o par PostgreSQL+PostGIS, que recentemente foi incluída na lista de bases de dados suportadas pela ESRI.

A partir da versão 9.3 a ESRI incluiu a possibilidade de utilizar, com toda a sua família de software ArcGIS, a base de dados PostgreSQL e o seu módulo geoespacial PostGIS, ambos Open Source. Esta possibilidade é muito atraente por vários motivos, sendo para mim os mais importantes:

  • PostgreSQL e PostGIS são produtos de grande qualidade, grande difusão, com utilizadores de referência credíveis, existindo uma comunidade muito activa ao seu redor;
  • São Open Source e gratuitos;
  • Oferecem funções de manipulação e análise geográfica de dados vectoriais através de SQL, ombreando com os melhores produtos existentes, open source ou comerciais;
  • Seguem os standards da indústria para SQL espacial (da OGC, e neste momento está em fase de implementar o standard da ISO), o que é obviamente uma abordagem irrepreensível e de enorme importância;
  • Quase a totalidade das aplicações SIG Open Source são compatíveis com esta bd;
  • O facto da ESRI incluir esta base de dados no grupo de sistemas suportados “oficialmente”, oferece uma segurança aos departamentos de TI que pode ser um factor decisivo na adopção ou não do PostgreSQL na empresa (e eu sei que este ponto gera polémica na comunidade de utilizadores e apoiantes, mas é um facto que existe esta barreira).

Porquê mudar?

Uma plataforma SIG muito comum, e aquela com que mais trabalho, é baseada em Oracle e ArcSDE, onde vários utilizadores de ArcGIS visualizam e editam a informação aí residente, havendo também servidores webGIS e aplicações que utilizam a informação residente em Oracle/ArcSDE. Neste artigo vou frequentemente referir esta arquitectura como ponto de comparação.

Quando já existe, trocar de base de dados não é tarefa fácil, consoante o volume e complexidade da informação existente, da dependência das aplicações desenvolvidas, e das novas competências que será necessário adquirir. Mas, há um  momento fulcral na vida de uma base de dados durante o qual vale tudo: a migração de servidor e upgrade de versão!

Nesta situação, a vantagem de migrar para PostgreSQL/PostGIS é passar a contar com um grande conjunto de aplicações SIG Open Source que podem usar a base de dados sem passar pelo ArcSDE – ou seja, podemos usar software não-ESRI e software ESRI para ler e manter a base de dados geográfica, efectivamente criando um sistema híbrido. (NOTA: uso aqui a expressão “SIG Híbrido” no sentido de integrar componentes comerciais e componentes Open Source num sistema de forma a usufruir das vantagens de cada componente, com as dificuldades inerentes, tal como Dan Dale Lutz tão bem explicou aqui.)

Note-se que esta interoperabilidade já é possível em alguma medida, especialmente com Oracle, desde que os dados sejam armazenados em Oracle Spatial ou Locator (sempre incluído em todas as versões Oracle). Só que neste caso existem muito menos aplicações SIG que lêem este tipo de dados, algumas Open Source. Mas em geral, as opções Open Source têm uma compatibilidade pouco fiável e de instalação nem sempre fácil. Por outro lado, tenho encontrado sistematicamente um desempenho muito inferior ao usar ArcGIS com dados Oracle Spatial quando comparado com o modo tradicional do ArcSDE armazenar dados em Oracle (denominado SDEBINARY). Mais sobre estas opções adiante…

Um sistema híbrido porquê?

O cenário de adoptar o PostgreSQL num SIG baseado em ESRI (ou Autodesk) implica que se pode manter todo o restante ecossistema SIG – ferramentas desktop, servidores webGIS, e aplicações desenvolvidas, bem como o nível de produtividade actual da equipa de edição/análise (que tipicamente é atingido após anos de experiência da equipa técnica com estas ferramentas). E ainda se abrem as portas para alargar o ecossistema a ferramentas  Open Source e de outros vendedores.

No caso da ESRI, todo o seu software comunica com o ArcSDE para chegar aos dados, e não directamente com a base de dados. Por isso a troca por outra bd não tem qualquer impacto sobre a restante plataforma SIG. E isto é uma vantagem. Claro que a desvantagem é o preço do ArcSDE…

No caso em que o ArcSDE já existe, podemos alegremente ignorar este custo (embora o custo de manutenção anual continue a existir)!! Em situações onde não exista ArcSDE deve-se incluir o seu custo de aquisição na análise das alternativas disponíveis.

A vantagem do SQL espacial

Um dos grandes trunfos de usar uma bd que, como o PostgreSQL+PostGIS, oferece funções de manipulação e análise espacial por SQL é podermos usar comandos na própria bd que vão efectuar as análises que estamos habituados a fazer apenas com as nossas ferramentas SIG desktop favoritas.  (Aliás, para ser exacto, o ArcSDE desde a v9.3 adiciona sempre o seu próprio dialecto de SQL espacial à bd onde é instalado, que pode ser usado como alternativa ao SQL nativo da bd. Isto também se aplica ao PostgreSQL. O administrador da bd é que decide se usa o dialecto da ESRI ou o dialecto nativo da bd.)

Por exemplo, com SQL espacial é possível seleccionar as classes de solo intersectadas pelo novo traçado do IP2, recorrendo apenas ao PostgreSQL, e sem usar ArcView. E como a máquina onde se instalam bases de dados é tipicamente muito mais potente que o nosso posto de trabalho, a velocidade de processamento destas análises será também superior. Já para não falar de evitar a transmissão de dados na rede entre a bd e o posto de trabalho. Apenas os resultados são transmitidos à aplicação SIG para visualização.

Então porque é que não estamos todos a usar SQL espacial para fazer análise geográfica?

Porque ainda é preciso que o utilizador saiba escrever estes comandos SQL! E isto não é uma tarefa trivial. Notem que escrevi “ainda é preciso saber…” sendo a palavra chave “ainda“. Isto porque hoje todas as bases de dados comerciais têm suporte a SQL espacial – Oracle, SQL Server, DB2, Informix – umas há mais tempo que outras, umas com SQL mais padronizado que outras, mas a funcionalidade está lá. O que falta são as aplicações que sabem executar essa análise nessas bd’s, facilitando a vida ao utilizador com botões e menus amigáveis, e dispensando assim o conhecimento de SQL espacial!

Por exemplo, quando o ArcView calcula um buffer não utiliza as capacidades da bd de cálculo de buffers, mesmo que elas existam. Apenas lê os dados armazenados na bd, e usa o nosso posto de trabalho para fazer o cálculo. E a esmagadora maioria das aplicações SIG actuais fazem o mesmo, quer comerciais quer Open Source.

Mas parece-me inevitável que ao longo dos próximos anos assistamos à mudança deste paradigma. Até porque desde que a Microsoft incluiu SQL espacial no SQL Server 2008 há toda uma nova geração de programadores que “acordou” para as capacidades do SQL espacial.

Quando uma aplicação SIG com peso no mercado conseguir fazer uma análise 10x mais rapidamente que os seus concorrentes (porque recorre às capacidades do servidor de base de dados) o que acham que vai acontecer?

Opções para utilizadores ESRI

Então que opções existem para os utilizadores ESRI que querem utilizar PostgreSQL+PostGIS?

ArcSDE

A opção standard do ponto de vista da ESRI é, claro, instalar o ArcSDE. Na versão 9.3 existe um setup de instalação que até instala o PostgreSQL e o PostGIS de uma forma muito automatizada. Pode-se encontrar alguns tutoriais de instalação, como este do Adriano Hantequeste: ArcSDE [Passo 1] Instalando o PostgreSQL. Há que ter atenção, no entanto, aos passos opcionais de instalar o PostGIS manualmente, para podermos no fim optar pelas suas capacidades nativas. (No manual de instalação do ArcSDE está tudo bem explicado.)

Mas há mais para além da instalação do ArcSDE. Podemos configurar a forma como o ArcSDE armazena os dados vectoriais no PostGIS. Existem 2 opções:

  • formato proprietário ESRI (ST_GEOMETRY)
  • formato nativo PostGIS (PG_GEOMETRY)

Estas opções definem o formato como as geometrias dos nossos vectores são armazenados na bd. Para o utilizador de ArcGIS é invisível se optamos por uma ou outra, mas há consequências importantes.

O formato ESRI guarda as geometrias no PostgreSQL de forma a que apenas se podem ler ou alterar usando software compatível (leia-se ESRI). Ou seja, o Quantum GIS para ler estes dados terá de usar um plugin ArcSDE (para ser exacto, o plugin é instalado no OGR que por sua vez é usado através do QGIS).

Por sua vez, o formato PostGIS guarda as geometrias usando as capacidades do PostGIS, e isso significa que todo o software compatível com PostGIS as pode ler e alterar. Ou seja, podemos carregar dados na bd usando o ArcCatalog (que passa pelo ArcSDE), e depois usar o QGIS para ler esses dados, sem passar pelo ArcSDE e sem plugins. Confuso? Espero que não… em última análise, esta opção permite ter na empresa aplicações gratuitas como o QGIS a usufruirem da bd central, a fazer impressões, análises, confrontações, etc. sem duplicação de dados ou conversões desconfortáveis.

Como se configura esta opção do formato de armazenamento das geometrias?

Sem querer entrar em grandes detalhes, pode-se dizer que é muito simples. Basta executar um comando que altera uma linha na tabela de configuração do ArcSDE. O comando é o seguinte:

sdedbtune -o alter -i 5151 -k DEFAULTS -P GEOMETRY_STORAGE -v “PG_GEOMETRY” -s <server_name> -D postgis -u sde -p <ArcSDE_admin_password>

Esta opção tem outras configurações e particularidades que terão de ficar para outra oportunidade.

zigGis

zigGIS é uma extensão para ArcGIS que permite ler e escrever em PostGIS, sem usar ArcSDE. É um produto que começou como Open Source, e que evoluiu para uma solução comercial. Embora a fonte do programa esteja disponível, é exigida a compra de licenças na maioria das situações (excepto para uso pessoal e académico que continuam isentos de pagamento – ver licença aqui).

Ora o preço é de apenas US $279! por posto de trabalho. É naturalmente muito apetecível. O cenário em vista é conseguir um SIG, com base de dados geográficos e aplicação desktop de topo, apenas pelo preço de ArcView + $279.  Será que há algum truque, uma armadilha? Parece que não, a ver pelo excelente exemplo da implementação na Câmara Municipal de Albufeira, é uma opção extremamente flexível.

O papel do ArcSDE

Claro que surge a questão óbvia: então para que serve o ArcSDE? Bom, esta questão é debatida há muitos anos, bem antes de existir o zigGIS, e posso apenas manifestar a minha opinião – o ArcSDE é o pivot de dados que serve toda a plataforma ArcGIS – desde o modelo de dados, ao servidor webGIS, às aplicações desktop. Sem o ArcSDE, as várias peças do ArcGIS “descolam”, e temos de recorrer a ficheiros para partilhar informação entre as componentes do sistema. Por outro lado, o ArcSDE permite à ESRI implementar funções para além dos standards. Em geral, os standards na área SIG e SQL são desenvolvidos mais lentamente que as aplicações desenvolvidas pelos maiores fabricantes. Por exemplo, antes de existir WMS já existiam servidores webGIS. Antes de existir standard de SQL espacial, já existiam bases de dados geográficos. Com o ArcSDE a ESRI implementa um modelo de dados com funcionalidade que não está padronizada pela indústria: rasters, terrains (para LIDAR), topologia com regras de validação automática, gestão de versões, gestão de histórico, bd’s distribuídas, sincronização de bd’s… bom, não é o meu papel “defender” o ArcSDE, mas encontro valor acrescentado no produto. Para os casos que não necessitam desta integração ou destas funções, fará menos sentido a sua aquisição. Para os outros casos…

Conclusão

Já vai longo este artigo… contra todas as regras de bom comportamento em blogs 🙂

Nos próximos tempos penso continuar este tema com mais alguns artigos, olhando com mais detalhe para a combinação PostgreSQL+PostGIS<->ArcSDE<->ArcGIS.

Para já, é certo que podemos contar com a possibilidade de criar sistemas híbridos com software ESRI e componentes Open Source, usando o melhor dos 2 mundos. E isso é um passo de gigante  que demorou décadas a chegar ao ArcGIS, mas finalmente aí está.

Balanço Open Source para SIG

Gestão, Inicial, Open Source, SIG, , , ,
Tempo de leitura: 3 min

Já há algum tempo que tenho planeado escrever sobre a integração entre Postgresql e ArcSDE, agora que a ESRI suporta esta combinação. Mas ao começar esse artigo dei por mim a reflectir sobre a utilização que faço de ambos os mundos – open e closed source…

Sou utilizador de software ESRI há muitos anos, e sou também utilizador de software Open Source em tempo igual. Curiosamente.

Sucede que comecei a trabalhar em SIG num projecto de investigação na universidade (no Instituto Superior de Agronomia, “antigo” Dept. de Eng.ª Rural), e em simultâneo iniciei o mestrado. No projecto de investigação trabalhei com Linux, aprendendo as bases deste SO que ainda hoje me servem – na altura não havia sistemas de distribuição de pacotes de software já pré-configurados… por exemplo, o sistema de email que usava tive que o compilar… outros tempos (sou tão velho “informaticamente” que a minha mulher quer oferecer-me pelo aniversário uma tshirt do ZX Spectrum). Para a tese de mestrado usei ArcInfo numa estação de trabalho IBM com o SO AIX, uma variante de Unix desenvolvido por este fabricante. Desde aí mantive o gosto por Open Source, e continuei utilizador ESRI.

Para um utilizador ESRI, a integração com software Open Source é uma questão muito pertinente, por vários motivos – anoto aqui apenas alguns. Afinal, e não o escondo, o ArcGIS é o meu software SIG favorito, mas não faz tudo o que preciso, e nem tudo o que faz é feito da melhor forma. Nada melhor do que complementá-lo com pérolas de software gratuito. Por outro lado, existem tarefas para as quais prefiro utilizar um programa mais ligeiro, como o QGIS. E claro, para tarefas relacionadas com outro software Open Source também não é o mais indicado. Por exemplo, exportar um ficheiro .map para o MapServer a partir de um mapa devidamente simbolizado. Também a interoperabilidade e capacidade de interagir com os diversos standards OGC são limitadas no ArcGIS em alguns aspectos. Por exemplo, criar ficheiros SLD (de simbologia) para uso no GeoServer. Mas para os críticos do ArcGIS não se ficarem a rir, não conheço nenhum outro programa que crie ficheiros KML tão facilmente e com tanta funcionalidade como o ArcGIS. E o KML também é um standard OGC…

A situação com o Software Aberto na área SIG (SASIG) teve uma evolução explosiva nos últimos anos. Na minha opinião, devido em grande parte à publicidade positiva que a área recebeu da Google e a Microsoft. E hoje o panorama de software no lado do servidor e no lado do desktop é extraordinário. O software Open Source não serve só como complemento, e terá todo o mérito e capacidade em ser utilizado como peça central de um SIG. Tudo depende dos objectivos, necessidades, e processos de trabalhos escolhidos.

No servidor, temos 3 players fenomenais: MapServer, GeoServer (web), e Postgresql+PostGIS (bd).

No desktop, podemos também escolher facilmente 3 campeões da causa: gvSIG, Kosmo, e Quantum GIS – embora existam muitos mais.

Na categoria de ferramentas para conversão de dados, que tanto são usadas no lado servidor como no lado desktop, temos o incontestável par GDAL/OGR para raster e vector. Outras iniciativas mais recentes que poderão ser interessantes são o FeatureServer, o Spatial Data Integrator e o GeoKettle (ambos semelhantes ao FME).

Para o desenvolvimento de aplicações web também temos óptimos produtos: OpenLayers, pmapper, MapFish, e vários outros.

Já para desenvolver aplicações desktop o cenário é muito diferente, e não será uma tarefa fácil tentar criar uma aplicação SIG baseada em componentes Open Source. Pessoalmente, a minha opção seria sempre pela facilidade de utilização, e assim optaria pelo objecto ActiveX do MapWindow GIS, ou o extraordinário SharpMap para .NET (cujo desenvolvimento tem sido extremamente lento, para grande desencanto da comunidade… o jovem Morten foi contratado pela… (suspense)… ESRI!). Estas seriam as opções mais simpáticas, com menor exigência técnica e de tempo para criar uma aplicação SIG desktop adaptada a um objectivo específico.

Para adeptos Java existem também várias opções, embora mais complexas. As opções mais proeminentes serão a GeoTools (sem mecanismo de visualização?), GISToolkit (última versão de 2003), e OpenMap (apenas visualização). O mundo Java é para mim mais desconhecido, e agradeço contribuições de quem tenha mais prática com esta tecnologia para esclarecer a situação actual face a componentes SIG.

A área continua a evoluir e é difícil manter uma noção actualizada do que vai acontecendo nos vários domínios. Têm vindo a ser publicados artigos com o diagnóstico da “situação actual”:

Faltará talvez uma página web fixa onde se possam actualizar os vários produtos, talvez num wiki? Para nós lusófonos, seria excelente manter uma página destas no wiki do OSGeo PT. Há voluntários???

Serviços SIG no AutoCAD

CAD, Intermédio, SIG, ,
Tempo de leitura: 4 min

Olá a todos. Desde o meu último post passou mais tempo do que gostaria… mas hoje consegui “empurrar” este post.

A questão que trago aqui hoje é uma forma de integrar um SIG baseado em software ESRI com software Autodesk. Ou seja, se a sua organização usa ArcGIS Server então saiba que pode fazer chegar toda a sua informação SIG aos utilizadores de AutoCAD/Map/Civil, e tudo sem conversões ou múltiplos ficheiros. Melhor, pode visualizar toda a informação publicada pela ESRI no site ArcGIS Online no AutoCAD, e isso inclui os ortofotomapas do IGP, de 2004 e com 1 m de resolução.

A solução é o plugin da ESRI “ArcGIS for AutoCAD”, para AutoCAD (como o nome indica). É um download gratuito que está no site da ESRI. Depois de instalado vai acrescentar um menu e uma ribbon ao AutoCAD chamados “ArcGIS” e que permitem definir ligações a serviços ArcGIS Server, localizados na Intranet ou na Internet, o que abre uma grande via de comunicação entre o mundo SIG e o mundo CAD. Este plugin oferece ainda uma nova forma de produzir informação CAD (no AutoCAD) com atributos denominada “Mapping Specification for Drawings” e que, de acordo com a ESRI Inc., é mais interoperável – não obriga a conversões complexas, evita perda de informação quer no lado SIG quer no lado CAD, e é baseado apenas em ficheiros DWG “normais”. Pode obter mais informação aqui: Mapping Specification for Drawings. Ainda não tive a oportunidade de investigar em detalhe esta nova opção… mas este video da ESRI ilustra o processo.

Mas regressemos ao tópico principal – como ver no AutoCAD informação publicada através do ArcGIS Server?

Instalação do ArcGIS for AutoCAD

A instalação segue o processo normal: depois de fazer o download, basta executar o ficheiro obtido. Nos casos que observei, os novos elementos na interface do AutoCAD não foram correctamente adicionados, pelo que foi necessário fazê-lo manualmente. Para isso bastou executar o comando “cuiload” (dentro do AutoCAD) e na janela que abre indicar o ficheiro “C:\Program Files\ArcGIS for AutoCAD\ afaUI.cui” (ou equivalente de acordo com a pasta de instalação).

A partir daqui, o menu e a ribbon ArcGIS ficarão visíveis.

Adicionar um serviço

Para adicionar um serviço ArcGIS, basta usar o botão “Add Map”, e preencher os dados do endereço do servidor, e nome do serviço pretendido. Na imagem seguinte é mostrada a ligação a um servidor interno na EDIA com um serviço que mostra as infra-estruturas do EFMA, usando dados ArcSDE e simbologia ArcMAP:

image

E o resultado depois de aproximar a uma área com dados é (desculpem a qualidade da imagem):

image

Podem ser usados serviços dinâmicos e de cache (em que as imagens são previamente geradas para uma quadrícula e para um conjunto de escalas pré-definidos). Os serviços de cache permitem uma velocidade de interacção muito maior, com a contra-partida de existir alguma desactualização dos dados.

Adicionar o serviço ArcGIS Online com os ortos do IGP

O processo para adicionar os ortos ao AutoCAD é o mesmo, mas agora indicando o endereço do servidor da ESRI: http://services.arcgisonline.com/arcgis/services.

No momento em que fiz este artigo, o AutoCAD não reconheceu o proxy da empresa (que exige autenticação), pelo que não pude capturar imagens… não foi possível determinar se o problema é do AutoCAD ou se é do plugin.

Identificar vectores num serviço ArcGIS Server

O plugin também inclui uma ferramenta de “Identify” que permite consultar os atributos da informação publicada. Por exemplo, identificar um canal no serviço da EDIA daria o seguinte resultado:

image

Conclusões

Esta ferramenta é realmente um passo em frente na interligação SIG-CAD, ou melhor, ESRI-Autodesk. Embora o AutoCAD Map e Civil tenham a capacidade de ligação a serviços WMS, a verdade é que a minha experiência com essa funcionalidade não tem sido a melhor (muitas vezes o mapa não redesenha o serviço WMS, e a impressão não refresca a imagem para ajustar ao tamanho do layout). Por outro lado, a ligação a serviços ESRI em cache é agora possível, o que traz as 2 grandes vantagens destes serviços: 1) são muito mais rápidos; e 2) exigem muito menos esforço por parte do servidor SIG, o que permite servir mais utilizadores com o mesmo servidor.

Neste momento, este plugin está em utilização na EDIA principalmente para visualizar, em AutoCAD, os mosaicos de ortofotomapas residentes em ArcSDE, algo que nunca tinha sido conseguido de forma funcional. E conseguimos mesmo chegar aos utilizadores da versão base do AutoCAD (sem Map nem Civil), que foram também sempre os mais excluídos do SIG. Optou-se por publicar os ortos através de serviços em cache, o que resultou numa óptima performance e numa experiência impressionante para os utilizadores.

No entanto, algumas questões têm suscitado dúvidas e dificuldades: a qualidade das imagens que surgem no AutoCAD têm pouca qualidade quando se utilizam serviços em Cache (principalmente vectores; com ortos não é tão aparente), e não foi ainda possível definir a transformação entre data diferentes (isto é, sobrepor dados WGS84 e Datum73). Também as labels aparecem no AutoCAD mais pequenas do que o esperado, o que obriga a alterar os mxd’s e criar novos serviços no ArcGIS Server especificamente para utilizar em AutoCAD.

Por outro lado, a possibilidade de definir níveis SIG num DWG que depois surgem no ArcMap como Feature Classes, sem necessidade de conversão, é muito apelativa… mais ainda se pensarmos que se podem preparar DWGs vazios com as especificações pretendidas e entregá-los a fornecedores de serviços, projectistas e arquitectos. Estes podem criar a sua informação usando AutoCAD com estes DWGs, trabalhando assim já de acordo com as especificações SIG dos clientes, e sem necessidade de adquirir novo software – bastará usar o plugin gratuito. Mas este é já outro desafio totalmente diferente…

Criar KML de Pontos no ArcGIS

Inicial, SIG, , ,
Tempo de leitura: 6 min

Um amigo que também anda nestas lides geoespaciais, pediu-me ajuda para perceber a melhor forma de passar um shapefile de pontos para KML, de preferência de forma a que os pontos tivessem “balões” de informação e com símbolos minimamente aceitáveis.

O shapefile contém pontos com alguns atributos em português, como Nome, Categoria, e outros. O aspecto inicial no ArcMap é este:

image

E o objectivo é chegarmos ao Google Earth com este aspecto:

image

Filtrar os dados

Como apenas alguns pontos interessam passar ao KML, vamos definir uma expressão de pesquisa. Nas propriedades do layer, no separador “Definition Query” construimos a query. Neste exemplo, queremos apenas os pontos cuja Categoria é igual a “Hotelaria”.

image

Ficamos assim com menos pontos a converter. É claro que este passo é opcional…

image

Sistema de Coordenadas

Os dados num ficheiro KML devem estar no sistema de coordenadas WGS84, indicando as coordenadas em graus de latitude e longitude.

Em vez de projectar o nosso shapefile, vamos em vez disso configurar a Data Frame para usar o sistema de coordenadas WGS84. O ArcMap permite definir também a transformação de Datum, e com isso ao exportar dados podemos optar por usar o sistema de coordenadas original ou usar o que está activo na Data Frame. Esta abordagem tem a vantagem de reduzir o n.º de ficheiros intermédios que criamos em disco.

Assim, para definir o sistema de coordenadas, basta abrir as propriedades da Data Frame (botão direito em “Layers” na árvore de temas, e clicar na opção “Properties“), e abrir o separador “Coordinate System”.

Aqui, selecionar na parte inferior da janela a opção Predefined -> Geographic Coordinate Systems -> World -> WGS 84.

Temos ainda de selecionar a transformação de datum que queremos usar. Na parte superior da mesma janela, clicamos no botão “Transformations“, e na janela que abre selecionamos na última opção em baixo, a transformação “Datum_73_To_WGS_1984_4“. Esta transformação usa os parâmetros de nível nacional publicados pelo IGP.

image

O resultado desta definição é obtermos um mapa já em coordenadas WGS84, que podemos ver no ArcMap na barra inferior onde são mostradas as coordenadas do cursor.

image

Usar simbologia apropriada

Uma das coisas a que a Google nos habituou foi a vermos uma simbologia mais imaginativa, usando icones grandes e coloridos para representar pontos.

Em geral, os técnicos de SIG não usam este tipo de simbologia, mas o ArcMap inclui um conjunto de símbolos deste género que poderemos usar. Basta ligar o estilo “ArcGIS_Explorer” para vermos as opções disponíveis. Para vermos estes símbolos basta clicar no botão “More Symbols” no editor de simbologia dos pontos:

image

E assim podemos escolher um símbolo mais ajustado à utilização em Google Earth. O ArcGIS ao converter o layer para KML vai criar um pequeno ficheiro png que incluirá no nosso KML, e que será usado pelo Google Earth.

Para exemplificar escolhi o simbolo de uma cama de hotel e o aspecto do mapa ficou assim:

image image

Incluir atributos

O KML é uma linguagem muito flexível, permitindo associar informação descritiva aos elementos vectoriais. O ArcGIS facilita o processo de passar atributos para o KML, automatizando o processo. Claro que o processo automático tem limitações, mas para quem não quer ou não sabe editar KML manualmente, este automatismo é muito útil, e pode dar bons resultados.

Vários elementos passam do ArcMap para o KML automaticamente:

  1. O nome do layer passa como nome da pasta que contém os pontos
  2. A descrição do layer no ArcMap (nas propriedades, separador “General“), passa para o “Snippet” que descreve o layer no Google Earth
  3. As Labels do ArcMap são usadas para dar um nome a cada vector no Google Earth, e a própria label vai surgir na imagem no Google Earth
  4. Se no ArcMap definirmos as propriedades de “HTML Popup“, o Google Earth vai mostrar essa informação quando clicarmos sobre um ponto
  5. Se houver uma legenda no Layout do ArcMap, será passada ao KML e mostrada no Google Earth como uma imagem sobreposta à imagem do terreno (“screen overlay“), podendo no processo de exportação escolher o canto no ecrã onde surgirá

A ferramenta HTML Popup é uma variante da ferramenta de Identify, mas que mostra os atributos do vector clicado numa janela HTML que podemos configurar. Na sua forma pré-definida os campos são mostrados de acordo com as definições do separador “Fields“. Por exemplo, podemos esconder campos, e alterar a “Caption” para mostrar nomes de campos em português ou mais perceptíveis para o utilizador.

Portanto, para começar temos de definir as propriedades do HTML Popup do nosso layer de pontos no ArcMap. Para isso, nas propriedades do layer, separador “HTML Popup“, basta ligar a opção de usar a ferramenta de HTML Popup, e ao clicar no botão Verify podemos ver como ficará a janela de popup.

image

Podemos ainda melhorar o aspecto da janela se mudarmos as “Captions” dos campos e escondermos os campos que não nos interessa mostrar (usando o separador “Fields“). O aspecto final ficaria assim:

image

Rótulos ou Labels

Se definirmos labels no nosso layer de pontos, estes textos serão usados como o nome de cada ponto no KML final, e serão também visíveis no mapa junto a cada ponto. Portanto será uma questão de se querer ou não ligar as labels do layer e escolher o campo, a fonte, tamanho, cor, efeitos, etc. Mais importante será definir a escala a partir da qual os textos são mostrados, e que será respeitada pelo Google Earth. Se tiver muitos pontos aglutinados esta opção é praticamente obrigatória.

Executar a ferramenta “Layer To KML“

Esta ferramenta encontra-se na Toolbox de Conversão, toolset “To KML“:

image

Uma vez que queremos exportar a nossa informação como pontos e não como uma imagem, a questão mais importante nesta ferramenta é *não* ligar a opção de “Return single composite image“. Na caixa de “Output File” temos de indicar o caminho para o ficheiro a criar que deve ter obrigatoriamente a extensão KMZ (o ArcMap irá criar uma pequena imagem .png para mostrar o nosso símbolo no Google Earth que será incluída no ficheiro KMZ). Por fim, é obrigatório indicar a escala máxima de visualização. Ou seja, só a partir desta escala é que a informação será mostrada pelo Google Earth.

Resultado Final

E é tudo. Basta agora que no Google Earth usemos a opção File->Open para abrir o nosso ficheiro KMZ e ver o resultado final.

image

Existem ainda alguns melhoramentos que poderemos fazer: alterar o nome do layer no ArcMap irá alterar o nome do layer no Google Earth. Podemos também criar um ficheiro xsl para criar uma visualização alternativa com melhor estilo e até incluir imagens nas nossas janelas de popup (O ArcGIS inclui alguns exemplos na «directoria de instalação\ArcGIS\Styles» que podemos usar como base).

Existem muitas ferramentas de criação de KML a partir do ArcGIS que começaram a aparecer já há alguns anos, quando o ArcGIS não oferecia qualquer possibilidade de conversão. Com o tempo, a ESRI foi incluindo mais capacidades de conversão. Hoje, já na versão 9.3, fiquei impressionado com as capacidades nativas do ArcGIS – conseguimos obter um KML já com alguma sofisticação, e usando um processo de conversão bastante simples recorrendo a ferramentas e definições familiares a qualquer utilizador de ArcGIS.

Ortofotomapas do IGP no ArcGIS Online

Inicial, SIG, ,
Tempo de leitura: 2 min

Como é natural, durante o EUE09 foram feitos alguns anúncios sobre as próximas versões do ArcGIS e sobre a direcção que os produtos irão seguir no futuro próximo(2009-2010).

Um dos pontos frisados pela Linda Hecht, Directora de Marketing da ESRI Inc., e depois pelo Sandro Batista, Director de IDI na ESRI Portugal, foi o serviço ArcGIS Online, onde têm vindo a ser publicados alguns recursos para utilizar em ArcMap, ArcGlobe, e em aplicações ArcGIS Server. Estes recursos são projectos .mxd ou temas em formato .lyr que se podem acrescentar aos nossos próprios mapas, e que fazem ligação a dados remotos residentes nos servidores da ESRI.
A intenção da ESRI é fazer evoluir este serviço para uma plataforma mais colaborativa, integrando o site com ferramentas do próprio ArcGIS. Será interessante ver como o conjunto irá funcionar e até que ponto os utilizadores serão receptivos a esta abordagem.

Mas foi feito um outro anúncio pelo Sandro, relativo ao ArcGIS Online e que para mim caiu como uma bomba, mas no bom sentido! Os ortofotomapas do IGP, do ano 2004, e com resolução de 1m, estão publicados no ArcGIS Online na forma de .mxd e .lyr para o ArcGIS, e na forma de serviços REST para integração nas aplicações ArcGIS Server.

Ou seja, os utilizadores de ArcGIS podem abrir uma nova sessão de ArcMap e adicionar um tema com ortofotomapas para todo o País e sem custos. E isto é realmente algo significativo para todo o sector SIG e até para o sector da informação cartográfica… deixo a cada um o exercício de reflexão sobre o impacto desta iniciativa. (Estes são os mesmos ortofotomapas que foram disponibilizados via Virtual Earth.)

Na minha perspectiva, peca apenas por ser limitada aos utilizadores ESRI. Mas disponibilizar a mesma informação de forma mais abrangente caberá naturalmente ao IGP e não à ESRI, que neste momento oferece aos seus utilizadores um brinde fantástico. Aliás, se alguém da ESRI estiver a ler isto pode ser que coloquem um link logo na página principal do vosso site para informar todos os seus utilizadores desta oferta. Para se fazer justiça, obviamente que o IGP está de parabéns porque é o detentor dos dados.

Portanto, para usufruirem desta prenda de Natal atrasada, basta irem ao site arcgisonline.esri.com, e seguirem os links “Free maps” e “World User Imagery”. Nesta página podem ver os metadados da informação, bem como vários links para utilização nos produtos ArcGIS, incluindo um link de um .mxd e outro de um ficheiro .lyr.

Se gravarem o ficheiro .lyr numa partilha em rede, todos os utilizadores de ArcGIS na vossa organização poderão adicionar os ortofotomapas aos seus projectos.

Cuidado no entanto com o sistema de coordenadas, que é WGS 84. Para que os ortos se alinhem com a vossa informação é necessário definir o sistema de coordenadas da Data Frame e também a transformação de datum que querem usar. Por exemplo, se os vossos dados seguirem o sistema Hayford-Gauss, datum 73 (vulgo IGP), então definam o sistema da Data Frame para “Datum 73 Hayford Gauss IPCC”, e nas Transformações escolham transformar de WGS 84 para Datum 73, usando a transformação #4 que corresponde aos parâmetros publicados pelo IGP. Claro que o melhor será seguir as excelentes instruções do Prof. José Alberto Gonçalves que permitem reduzir os erros de conversão para uns míseros centímetros!