Java Spatial for PostgreSQL and H2

Hoje quero comentar o lançamento do Jaspa 2.0 (JAva SPAtial for PostgreSQL and H2). O Jaspa é uma extensão espacial para bancos de dados relacionais que introduz diversas funcionalidades que podem existir (ou não nativamente) nestes RDBMS.

O projeto é mantido pelo Dep. de Engenharia Cartográfica da Universidade Politécnica de Valência. Ponto pros caras!

Como diz o nome, é escrito em Java e está disponível para estes RDBMSs que suportam a linguagem. O projeto é bem interessante, especialmente para desenvolvedores. Não reinvente a roda. Use uma pronta e mais redonda!

O post de hoje foi patrocionado por Led Zeppelin e Johnny Cash.

Um abraço,

George R. C. Silva

Related posts:

1. Cascading Class Extensions

Confira:

• MapFish 2.2
• JTS
• GeoTools

Se você é um geonerd, confira. Todas tem código fonte disponível e são extremamente robustas.

Abraços

George R. C. Silva

Related posts:

1. Udig 1.2 lançado
2. GIS StackExchange Beta público
3. Integração CAD/GIS

Hoje estou trabalhando em um projeto comp

lexo com requisitos, bem, acima da média. Nosso usuário é bastante exigente e com razão. Há uns milhares de posts atrás, falei sobre class extensions aqui e aqui.

Class extensions são uma forma muito poderosa se customizar o comportamente básico do ArcGIS, em qualquer versão ou em qualquer ambiente. Elas funcionam em Java, C#, com server, em desktop e com ArcEngine. São praticamente universais para os produtos ESRI. Além disso, são relativamente fáceis de implementar e não possuem muitos requisitos.

Só possui um único requisito de deploy:

• O código desenvolvido necessita estar na máquina (cliente, server, ou qualquer coisa que o valha - e claro, não o código, mas sim os binários que foram gerados);

E uma limitação:

• Uma tabela ou feature class, só pode ter uma e somente uma, class extension.

Tudo bem até aí. Nos primeiros posts falei de class extensions que poderiam herdar funcionalidade de outras class extensions. Mas o código cresce rapidamente e se temos que cuidar de um ou mais comportamentos na mesma class extension, isso pode ficar simplesmente insuportável para o desenvolvedor.

Uma outra maneira de se fazer as coisas é através de composição. Ao invés de criarmos uma hierarquia complexa de class extensions, na qual a CE mais específica deriva da CE mais geral, foi necessário construir uma class extension que fosse extensível, mas sem recompilar o código e sem afetar o funcionamento básico de outras funcionalidades.

Uma das partes do problema é que elas são configuráveis através de um conjunto de dados, o objeto IPropertySet. Acessá-lo não é difícil, mas traz uma chateação à mais para o desenvoledor.

Bem, o que fizemos: abstraimos toda a funcionalidade da class extension. A única class extensions verdadeira que temos contém uma referência à um grupo de classes que implementam as funcionalidades, mas não são registradas na classe. Isso nos permite adicionar e ou remover uma parte da funcionalidade sem afetar as outras.

Temos basicamente três objetos principais:

• Uma class extension geral (a quem chamamos de polimórfica);
• Um ClassExtensionContainer (que segura referências à outras classes que fazem todo o trabalho);
• Uma fábrica de ClassExtensionContainer. Como não queremos que a nossa class extension determine quais serão as funcionalidades que ela executará, não podemos deixar à cargo da mesma a criação do nosso container.

Agora, por que separar esses caras assim? Bem, queremos que nossa class extension (que será registrada com nossa feature class ou tabela) consiga ser executada, independente do que existe no container. E não queremos que ela crie o container, pois bem, existem várias maneiras de criá-lo, e.g. chamada direta, lendo um arquivo texto ou até mesmo acessando um banco de dados. Por isso criamos a fábrica. Se quisermos mudar a maneira de como criar o container, só mudamos a fábrica e não nosso projeto completo.

Bem, o projeto é mais ou menos assim:

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
using Core.Model;
using ESRI.ArcGIS.ADF.CATIDs;
using ESRI.ArcGIS.Editor;
using ESRI.ArcGIS.esriSystem;
using ESRI.ArcGIS.Geodatabase;
using log4net;
using ILog = log4net.ILog;

namespace Core.Extension.ModelExtension
{
    [Guid("32f7294c-eaf3-4df1-90aa-03e2828f305e")]
    [ClassInterface(ClassInterfaceType.None)]
    [ProgId("Core.Extension.ModelExtension.PolymorphicExtension")]
    public class PolymorphicExtension :
        BaseClasse,
        IInterfaceCustomizadaQueImplementaInterfacesESRI, // IClassExtension, IObjectClass, etc.
        IObjectInspector
    {

        // código de registro com removido 

        private IClassExtensionContainer _container;

        public override void Initialize()
        {
            var dataset = (IDataset)_helper.Class;
            _elementType = DetermineElementType(dataset);
           // inicializamos o container.
            _container = ClassExtensionContainerFactory.CreateContainer(_elementType);

            // inicializamos outras class extensions, que talvez precisem de serem inicializadas!
            foreach(var ext in _container.Extensions)
            {
                ext.Init(_helper, null);
            }
        }

        public override void Shutdown()
        {

        }

        public override void OnChange(IObject obj)
        {
            foreach (var ext in _container.Extensions)
            {
                _log.InfoFormat("Disparando OnChange de {0}", ext.ExtensionName);
                ext.OnChange(obj);
            }
        }

        public override void OnCreate(IObject obj)
        {
            foreach(var ext in _container.Extensions)
            {
                _log.InfoFormat("Disparando OnCreate de {0}", ext.ExtensionName);
                ext.OnCreate(obj);
            }
        }

        public override void OnDelete(IObject obj)
        {
            foreach(var ext in _container.Extensions)
            {
                _log.InfoFormat("Disparando OnDelete de {0}", ExtensionName);
                ext.OnDelete(obj);
            }
        }

        public override string ValidateField(IRow row, string fieldName)
        {
            _log.InfoFormat("Validando campo {0}",fieldName);

            var sb = new StringBuilder();

            foreach (var ext in _container.Extensions)
            {
                try
                {
                    _log.InfoFormat("Validando extensão {0}", ExtensionName);
                    sb.AppendLine(ext.ValidateField(row, fieldName));
                }
                catch (Exception ex)
                {
                    _log.ErrorFormat("Ocorreu um erro ao tentar validar o campo {0} em {1}", fieldName, ExtensionName);
                    _log.Error(ex.Message, ex);
                    continue;
                }
            }

            return sb.ToString();
        }

        public override string ValidateRow(IRow row)
        {
            _log.Info("Validando linha");

            var sb = new StringBuilder();

            foreach (var ext in _container.Extensions)
            {
                try
                {
                    _log.InfoFormat("Validando extensão {0}", ExtensionName);
                    sb.AppendLine(ext.ValidateRow(row));
                }
                catch (Exception ex)
                {
                    _log.ErrorFormat("Ocorreu um erro ao tentar validar a linha em {0}", ExtensionName);
                    _log.Error(ex.Message, ex);
                    continue;
                }
            }

            return sb.ToString();
        }

        public void Inspect(IEnumRow objects, IEditor editor)
        {
            _container.CustomInspector.Inspect(objects, editor);
        }

        public void Clear()
        {
            _container.CustomInspector.Clear();
        }

        public void Copy(IRow srcRow)
        {
            _container.CustomInspector.Copy(srcRow);
        }

        public int HWND
        {
            get { return _container.CustomInspector.HWND; }
        }
    }
}

A principal sacada neste caso, é o nosso container. Ele contém uma referência para uma interface customizada, que implementa a parte principal dos comportamentos, que são:

• IObjectClassExtension
• IClassExtension
• IFeatureExtension
• IObjectClassEvents
• IObjectClassValidation
• IObjectInspector (este cara aqui é para customizarmos o painel de edição default do ArcGIS! nosso container também contém ele!)

Estas interfaces da ESRI que vão segurar toda nossas funcionalidades, quaisquer que sejam. Segue nosso container:

public interface IClassExtensionContainer
 {
 List<ICustomClassExtension> Extensions { get; }
 IObjectInspector AirspaceInspector { get; }
 }

Ele é só isso. A mágica fica na fábrica, que preenche este camarada e passa ele para nossa extensão de verdade. Depois que o container foi inicializado, durante o método Init() da classe principal - a própria CE inicializa as outras;

Este padrão é seguido nos outros métodos. Ela delega para as classes que contém funcionalidade as ações que devem ser executadas. Desta maneira conseguimos múltiplos comportamentos customizados e uma facilidade enorme para adicionar ou removê-los.

Por isso o nome de Cascading Class Extension. Na realidade, temos única class extension que cuida de tudo para nós, cascateando todo o comportamento interessante para nós.

O que acharam? ArcObjects não é complicado, é cheio de manhas. Depois que as conhecemos, fica muito fácil!

Ah, em nota: tenho desenvolvido algum código baseado em ArcObjects que vou disponibilizar em breve. Assim que disponibilizar, você poderá ver esta implementação acima, completa!

Abraços

George R. C. Silva

Related posts:

1. ArcObjects e Class Extensions #2
2. ArcObjects e Class Extensions #1
3. Hello World, ArcGIS style!

Trabalhei durante quase um ano na Logica e tive excelentes momentos. Conheci pessoas muito interessantes, fiz amigos e aprendi muita coisa durante meu período lá.

Outros ventos me levaram para outra(s) empresas, mas ainda mantenho contato com o pessoal de lá e aqui vem a boa notícia: eles estão com uma vaga aberta para um desenvolvedor ESRI. A empresa é boa, os benefícios espetaculares e os projetos desafiadores.

Segue a descrição da vaga!

Analista GIS Sênior

Þ   Assistência médica e odontológica Care Plus familiar (com apartamento), sem desconto em folha

Þ   Previdência Privada – Itaú Vida e Previdência S/A (com participação da empresa)

Þ   Ticket Refeição de 400,00 mensais (que podem ser convertidos em Ticket alimentação)

Þ   Seguro de Vida Sul América

Þ   Vale transporte na forma da lei

Þ   PLR (Participação nos lucros e resultados) conforme acordo coletivo da categoria

Þ   Auxílio creche (R$ 200 por mês para o primeiro filho e R$ 130 para os demais) até completarem 5 anos de idade

Þ   Celular da empresa

Þ   Férias

Þ   FGTS

Þ   13º

Þ   Dissídio anual

Enviem currículos para:

Hugo.amadeu@logica.com

Adriana.hiromi@logica.com

Abraços
George

Related posts:

1. Mercado de Trabalho e curiosidades
2. Contribuindo um pouquinho…
3. Máquina Virtual e Desenvolvimento para ArcObjects

Depois de um tempinho apareço denovo! Hoje quero falar um pouco sobre padrões de projeto (Design Patterns) e a como acessar dados via ArcObjects.

Como vocês sabem, os objetos da ESRI são bastante chatinhos de se trabalhar. Eles tem peculiaridades incríveis e se nos esquecermos delas vamos acabar nos dando mal! A grande questão estamos falando de uma biblioteca enorme e temos, com certeza, algumas interfaces centrais. Duas delas, com certeza são IObject e IObjectClass.

Em termos simples, IObject é uma linha de uma tabela, enquanto IObjectClass representa a tabela como um todo. Quase tudo que armazenamos dentro de um geodatabase é uma IObjectClass e seus filhotes, um IObject – até mesmo rasters.

Mas porque é tão difícil acessar e manipular as informações utilizando a API da ESRI? Bem, não é que é difícil. Para coisas pequenas é bastante tranquilo e simples, exemplo:

public class LeitorValores
{
	// esta classe lê os valores de uma tabela
	// ou feature class e os escreve na console.

	private IWorkspace _Workspace;
	private ITable _Tabela;

	public LeitorValores(IWorkspace workspace,string nomeTabela)
	{
		_Workspace = workspace;
		_Tabela = ((IFeatureWorkspace)workspace).OpenTable(nomeTabela);
	}

	public LerValores()
	{
		// poderiamos ter configurado o filtro como parâmetro

		IQueryFilter filter = new QueryFilterClass();
		filter.WhereClause = "";
		// a query está vazia, pois queremos ler e escrever todos os valores;

		ICursor cursor = _Tabela.Search(filter,true);

                // aqui poderíamos ter utilizado a interface mãe: IObject
                // IObject tempObject = null;		

                IRow tempRow = null;
		// tempObjectt = cursro.NextRow() as IObject
		while ((tempRow = cursor.NextRow()) != null)
		{
			for (int i = 0; i <= tempRow.Fields.FieldCount -1; i++)
			{
				Console.Write(tempRow.get_Value(i).ToString());
				Console.Write("\t");
			}
			Console.WriteLine();
		}
	}
}

É um classe bem simples, mas repare no seguinte fluxo:

1. Construímos uma query vazia (equivalente à “SELECT * FROM TABLE”);
2. Pedimos um ICursor (o cursor é um objeto que lhe permite navegar por linhas da tabela de forma ordenada, forward only, ou seja, só permite Next, e não Previous);
3. Iteramos pelo cursor, pegando cada linha da tabela e percorrendo suas colunas, uma à uma para buscar seu valor;

Note que só temos uma forma de ler o valor de uma coluna: utilizando o método get_Value(int i);

Para exemplos simples, não existem problemas, mas porém quando estamos falando de um sistema maior e que necessita de ser bem estruturado, como sabemos em nossos arquivos de código que o campo n é necessariamente, NomeRodovia, por exemplo? Se mudarem o modelo (por qualquer motivo) nosso código vai falhar (ou pior, vai funcionar e vai começar à nos passar valores errados – de coluna).

Deve existir um jeito mais fácil! Bem, existem algumas alternativas:

• Passar todo o acesso à dados para um framework ORM (Object Relational Mapping), por exemplo, NHibernate, Fluent NHibernate, Entity Framework entre outros;
• Utilizar ADO.NET puro;
• Ficar maluco tentando escrever ArcObjects esperto o suficiente para dar conta de seus problemas;

As alternativas, estão em ordem: da melhor para pior. O primeiro caso, de um ORM, teremos maior controle sobre nossas coisas, classes específicas para cada entidade ou para cada punhado de entidades (de acordo com sua necessidade) e teremos uma camada de domínio forte.

Mas ORMs comuns tem um problema: não utilizam as interfaces nativas do ArcObjects para acesso à dados, e nos leva, novamente as famosas gambetas. Exemplo: é ótimo acessar dados diretamente do banco de dados. É, em termos, mais rápido, mais confiável.

Mas inviabiliza completamente o uso de versionamento (pelo menos o nativo do ArcSDE), topologia, histórico, entre outras coisinhas mais, as quais pagamos à ESRI. Ou seja, estamos mutilando, para nosso próprio benefício (como desenvolvedor – facilitar nosso trampo!) o software que nosso cliente comprou.

Nenhuma das outras alternativas é muito atraente pois incentiva os desenvolvedores à prática feia do Ctrl+C/Ctrl+V – você acaba tendo de repetir querys e regras de negócio por todo o código e você arruina qualquer chance de testabilidade (a capacidade de testar e garantir que seu código funciona!)

Bem, a outra alternativa, é tentar: olhe bem, eu disse tentar, utilizar um padrão de projeto para dar conta de todos esses problemas que enfrentamos. Criar uma forma de acessar os dados dentro do geodatabase utilizando as ferramentas nativas, ou seja, ArcObjects.

É um desafio e tanto, já que é muito difícil controlar alguns aspectos desses objetos. (maldito erro COM! quem já viu um “COM object that has been separated from it’s underlying RCW cannot be used” sabe do que eu estou falando.)

Após estudar e fazer diversas tentativas de escrever algo que funcionasse, fosse de certa forma perfomático (pelo menos na mesma velocidade do acesso nativa aos objetos ou até um cadinho mais lento) e trouxesse produtividade, cheguei à um padrão projeto interessante: ActiveRecord.

É um padrão que basicamente tem um objeto vindo do banco de dados e propriedades que expõem comportamentos básicos de acesso e escrita ao objeto. Outro componente essencial é um repositório (outro padrão de projeto), que vai ser o responsável por conhecer nossas regras de acesso e como chegar ao banco de dados.

Um exemplo simples e não completamente estruturado:

public class Lote
{
	private IObject _ObjetoBanco;

	public Lote(IObject lote)
	{
		_ObjectBanco = lote;
	}

	public int IdentidadeLote
	{
		get { return Convert.ToInt32(_ObjetoBanco.get_value(1)); }
		set { _ObjetoBanco.set_Value(1); }
	}

	public string NomeProprietario
	{
		get { return _ObjetoBanco.get_Valeu(2).ToString(); }
		set { _ObjetoBanco.set_Value(2).ToString(); }
	}

	public void Salvar()
	{
		// comando ArcObjects para persistir o objeto na base
		_ObjetoBanco.Store();
	}
}

Veja que conseguimos mapear nossas colunas em único lugar e tratar este objeto por igual em qualquer lugar de nossa aplicação?

O problema de nosso primeiro exemplo, enquanto ele funciona, misturamos diversas funcionalidades e resposabilidade distintas em um único objeto. Ele sabe como ir ao banco, como mapear as colunas, e como jogá-las na tela. Caso precisássemos de ir ao banco novamente, em outra ocasião, teríamos de escrever a query novamente.

Existem outros padrões que podem auxiliar na mesma tarefa, mas a grande questão está na presença de código ArcObjects. Sem ele, fica difícil garantir que tudo funciona.

Existem duas implementações .NET para o padrão Active Record:

• Castle Active Record (que é construído em cima do NHibernate);
• nHydrate

A grande idéia aqui, é estudar o código de ambos e trazer uma implementação utilizando código ArcObjects. Não sei se é uma grande idéia, ou se não tem absolutamente valor algum (outras alternativas já são melhores).

Já tenho algo em desenvolvimento e quem tiver interesse, entre em contato que disponibilizo o link para o controle de versão do código.

E aí pessoal, o que acharam? São tópicos razoavelmente avançados, mas nada muito difícil de compreender. Fiquem à vontade para tecer comentários.

Abraços

George R. C. Silva

Related posts:

1. ArcObjects e Class Extensions #2
2. ArcObjects e Class Extensions #1
3. Cascading Class Extensions

Buenas noches. Estamos aí novamente!

Hoje gostaria de falar um cadinho sobre o mercado de trabalho. Não estou precisando de emprego, ainda bem, mas por curiosidade fiz uma pesquisa em um grande site de currículos e encontrei algumas vagas. O termo buscado foi geoprocessamento. Dessa curiosidade, encontrei outras curiosidades!

Vamos lá, primeiro a metodologia: o único termo de busca que usei foi “geoprocessamento” na página inicial, só olhei a primeira página e não adicionei nenhum outro filtro.

O resultado foi de 27 vagas em 19 anúncios. Tem gente precisando de mais de uma pessoa por aí.

Por cidade:

• 5 vagas para São Paulo;
• 3 vagas para BH e 3 para PoA;
• 3 para Angola;
• 1 vaga para Araraquara

O mercado está então concentrado em São Paulo? Sim e não. As vagas para São Paulo, 4 são para desenvolvimento e uma para Analista de Inteligência de Mercado (seja lá o que for isto).

Estas quatro vagas de desenvolvimento são realmente de desenvolvimento. Uma com plataformas mais esotéricas e as outras três para:

• Atuar com análise de sistemas, documentação em UML, programação Visual Basic 6 (VB6), PL/SQL, HTML, .NET, C# e banco de dados Oracle.
• Experiência nas atividades citadas.
• Ensino Superior em Informática, Engenharia ou Matemática.
• Desejável conhecimentos em Map Object, ArcObjects, geoprocessamento, software Arc View, Arc Gis e Arc Gis Server e aplicações em ArcGIS Server utilizando Microsoft .Net. C#.

Já as vagas de BH e de PoA são para produção.

BH:

• Atuar na conversão de dados para o ambiente geomedia, padronização e organização do banco de dados, análise espacial por agregação das ocorrências em linhas de transmissão, geração de layout e mapas temáticos.
• Experiência com ArcGis, Microstation, Cartografia/Geodésia e GeoMedia.
• Ensino Superior em Geografia e Pós-graduação em Geoprocessamento, Admistração e TI.
• Inglês técnico.

Porto Alegre:

• Responsável pelo processamento de imagens de satélite (sensoriamento remoto), processamento de dados cartográficos, integração de dados para geração de mapas e cartas temáticas, estruturação de relatórios técnicos, análise multicriterial e banco de dados geográfico.
• Experiência nas atividades relacionadas.
• Ensino Superior em Geologia, Engenharia, Análise de Sistemas ou áreas afins.
• Cursos de aplicação avançada de softwares de geoprocessamento e sensoriamento remoto.

Já as outras vagas sempre misturam “bons conhecimentos de geoprocessamento” com AutoCAD ou Microstation e CorelDraw. Humn, não sei se são muito para profissionais de Geoprocessamento.

A melhor vaga é a seguinte, para Porto Alegre. Peço de antemão desculpas pelo carnaval que se segue:

• Ensino Superior cursando em Engenharia Cartográfica de Agrimensura, Agronomia, Geografia ou Tecnologia da Informação.
• Realizar conversão de dados, gerados por levantamentos topográficos e GPS, edição e geração de base de dados cartográficos em softwares CAD, edição e estruturação de base de dados para SIG, além de eventuais processamentos digitais de imagens.
• Desejável experiência em sistemas de cartão de crédito, convênio ou gestão de frotas, frente de caixa, vivência em sistemas de meios de captura para cartão de crédito (POS, TEF, Webservice, etc), experiência em gestão de projetos e desenvolvimento de software no formato FS, conhecimento nos padrões de intercâmbio de dados geográficos (KML, GML, WMS, WFS, WPS).
• Conhecimentos em banco de dados Sybase, Oracle ou SQL Server, banco de dados geográficos, PostgreSQL, PostGIS (Oracle Spatial e MyGIS), especificação de software e elaboração de casos de teste, modelagem UML, modelagem relacional, modelagem de dados geográficos, Enterprise Architect, projetos de sistemas Web utilizando uma das tecnologias (Java, Coldfusion, PHP ou ASP), especificação e desenvolvimento em WebGIS, preferencialmente com google Maps API e/ou Bing e OpenLayers; GeoServer, Mapserver ou similares.conhecimento da ferramenta RPM (Rational Portfólio Manager) de gestão de projetos. conhecimento de ISO 8583.
• Deve se parecer com o cara da foto abaixo. (este é por conta do blog)

Não alterei nenhuma palavra da descrição da vaga, apenas coloquei o item “Ensino superior cursando” no topo e adicionei o último item. Salário? À combinar.

Gente, profissional de geoprocessamento (geoprocessadores?) não é faz tudo. É uma área especializada que vem crescendo no Brasil, mas funciona assim:

• Um gerencia;
• Um específica;
• Dois desenvolvem;
• Dois produzem dados;

Todas as vagas são coerentes, com exceção desta apresentada acima. Mas podemos tirar as seguintes conclusões:

1. O mercado para Geoprocessamento está aquecido. Seja para produção de dados ou para desenvolvimento de software;
2. Geoprocessamento ainda é meio que um mito no meio empresarial/corporativo. Aposto que tem gente aí que nem tem idéia do que seja.
3. São Paulo e Minas estão bombando (essas são as vagas anunciadas em um único site).
4. Se você está buscando um emprego, vá em frente, mas abra o olho! Pode ser fria!

E aí, o que vocês tem achado do mercado de trabalho no Brasil? Pessoal da Terrinha, como andam as coisas por aí? Dê sua opinião!

Um abraço pessoal,

George R. C. Silva

Related posts:

1. Vaga trabalho Logica
2. Sql Server 2008 e o sistema de uma projeção só
3. GeoInfo 2010

Lembram do artigo #1 sobre as class extensions? Falei um pouco sobre como as CEs funcionam? Dê lida aqui antes de ler este aqui.

Bem, as class extensions são um pouco difíceis de se manter, pois elas geram muito código, são controladas de forma esotérica (através de IPropertySet’s) e podem controlar alguns eventos importantes, como OnChange, OnCreate e OnDelete bem como as validações de uma feição.

Portanto, qual é uma maneira um pouco mais sã de construí-las? Uma primeira tentativa que fiz, foi utilizar herança para construí-las. Uma classe base com algumas funcionalidades era herdada por classes mais “abaixo” na cadeia e ia herdando funcionalidade. Mas como dizem por aí, composição é melhor que herança para extensão de função.

Na figura acima, percebemos que toda a funcionalidade é herdada através de herança. Todas as operações em OldBaseClassExtension (a mãe de todas) são marcadas como virtual, dando a possibilidade de sobreescrevemos o método pela classe filha.

Em código temos algo assim:

    public interface IOldClassExtension : IClassExtension, IObjectClassExtension, IObjectClassValidation, IObjectClassEvents
    {
        // aqui dizemos que todas as classes derivadas de IOldClassExtension
        // devem implementar os métodos das interfaces correspondentes.
    }

    public class OldBaseClassExtension:IOldClassExtension
    {
        public virtual void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            throw new NotImplementedException();
        }

        public virtual void Shutdown()
        {
            throw new NotImplementedException();
        }

        public virtual string ValidateField(IRow Row, string FieldName)
        {
            throw new NotImplementedException();
        }

        public virtual string ValidateRow(IRow Row)
        {
            throw new NotImplementedException();
        }

        public virtual void OnChange(IObject obj)
        {
            throw new NotImplementedException();
        }

        public virtual void OnCreate(IObject obj)
        {
            throw new NotImplementedException();
        }

        public virtual void OnDelete(IObject obj)
        {
            throw new NotImplementedException();
        }
    }

    public class OldConcreteClassExtensionA : OldBaseClassExtension
    {
        public override void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            base.Init(ClassHelper, ExtensionProperties);
            // nova funcionalidade customizada
        }

        public override void Shutdown()
        {
            base.Shutdown();
            // nova funcionalidade customizada
        }

        public override string ValidateField(IRow Row, string FieldName)
        {
            base.ValidateField(Row, FieldName);
            // nova funcionalidade customizada
            return "resultado de nova validação de campo";
        }

        public override string ValidateRow(IRow Row)
        {
            base.ValidateRow(Row);
            // nova funcionalidade customizada
            return "resultado de nova validação de linha";
        }

        public override void OnChange(IObject obj)
        {
            base.OnChange(obj);
            // nova funcionalidade customizada
        }

        public override void OnCreate(IObject obj)
        {
            base.OnCreate(obj);
            // nova funcionalidade customizada
        }

        public override void OnDelete(IObject obj)
        {
            base.OnDelete(obj);
            // nova funcionalidade customizada
        }
    }

    public class OldConcreteClassExtensionB : OldBaseClassExtension
    {
        public override void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            base.Init(ClassHelper, ExtensionProperties);
            // nova funcionalidade customizada
        }

        public override void Shutdown()
        {
            base.Shutdown();
            // nova funcionalidade customizada
        }

        public override string ValidateField(IRow Row, string FieldName)
        {
            base.ValidateField(Row, FieldName);
            // nova funcionalidade customizada
            return "resultado de nova validação de campo";
        }

        public override string ValidateRow(IRow Row)
        {
            base.ValidateRow(Row);
            // nova funcionalidade customizada
            return "resultado de nova validação de linha";
        }

        public override void OnChange(IObject obj)
        {
            base.OnChange(obj);
            // nova funcionalidade customizada
        }

        public override void OnCreate(IObject obj)
        {
            base.OnCreate(obj);
            // nova funcionalidade customizada
        }

        public override void OnDelete(IObject obj)
        {
            base.OnDelete(obj);
            // nova funcionalidade customizada
        }
    }

    public class OldConcreteClassExtensionC : OldConcreteClassExtensionA
    {
        public override void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            base.Init(ClassHelper, ExtensionProperties);
            // nova funcionalidade customizada
        }

        public override void Shutdown()
        {
            base.Shutdown();
            // nova funcionalidade customizada
        }

        public override string ValidateField(IRow Row, string FieldName)
        {
            base.ValidateField(Row, FieldName);
            // nova funcionalidade customizada
            return "resultado de nova validação de campo";
        }

        public override string ValidateRow(IRow Row)
        {
            base.ValidateRow(Row);
            // nova funcionalidade customizada
            return "resultado de nova validação de linha";
        }

        public override void OnChange(IObject obj)
        {
            base.OnChange(obj);
            // nova funcionalidade customizada
        }

        public override void OnCreate(IObject obj)
        {
            base.OnCreate(obj);
            // nova funcionalidade customizada
        }

        public override void OnDelete(IObject obj)
        {
            base.OnDelete(obj);
            // nova funcionalidade customizada
        }
    }

Perceba como determinamos a funcionalidade nas classes filhas: além de herdarmos e sobreescrevermos o método, chamamos também o método base, através de base.OnChange(obj), por exemplo.

Ok, funciona, mas quando temos algumas Class Extensions e uma hierarquia com dois ou três níveis já se torna impossível de manter e debugar o código. Demora-se muito para atingir um resultado razoável.

Como faríamos se usássemos composição? Bem, vamos imaginar o seguinte: temos algumas tabelas que descrevem as class extensions de acordo com sua funcionalidade básica (nem todas as CEs precisam implementar IObjectClassValidation, caso não às usem) e uma forma de ler e instanciar estas CEs de acordo com esta tabela. O diagrama de classes seria basicamente este aqui:

Desta maneira temos um código muito mais simples e nenhuma dependência entre cada ClassExtension. Todas as CEs implementariam ICustomClassExtension, pois esta dá visibilidade para todos os eventos / validações (poderíiamos até ter implementado IObjectInspector para dar formas diferentes de edição à cada CE) que precisamos e o sistema faria o restante, consultado o banco de dados (poderia esta dentro de um próprio FileGeodatabase/ArcSDE) e descobrindo à ordem e quais CEs devem ser instanciadas.

O esquema em SQL ficaria parecido com:

CREATE TABLE ENTIDADES
(
  -- conterá uma lista de feature classes ou de tabelas do ArcGIS
  nome_entidade varchar(128) NOT NULL, -- Lote
  nome_feature_dataset varchar(128) NOT NULL DEFAULT '', -- nome do feature dataset, caso exista
  nome_feature_class varchar(128) NOT NULL, -- nome da feature class, ex: FLTE_LOTES
  CONSTRAINT entidades_pk PRIMARY KEY (nome_entidade)
)

CREATE TABLE CLASS_EXTENSIONS
(
  -- conterá uma lista das class extensions disponíveis em determinada assembly.
  nome_class_extension varchar(128) NOT NULL, -- Validar Geometria de Lote
  descricao_namespace varchar(128) NOT NULL, -- ValidateParcelGeometryExtensions
  CONSTRAINT class_extensions_pk PRIMARY KEY (nome_class_extension),
  CONSTRAINT descricao_namespace_un UNIQUE (descricao_namespace)
)

-- tabela de relacionamento entre entidades e class extensions
-- é um relacionamento M:N
CREATE TABLE ENTIDADE_POSSUI_CLASS_EXTENSION
(
  nome_entidade varchar(128) NOT NULL REFERENCES ENTIDADES on (nome_entidade),
  nome_class_extension varchar(128) NOT NULL REFERENCES CLASS_EXTENSIONS on (nome_class_extension),
  ordem_criacao integer NOT NULL DEFAULT 0,
  CONSTRAINT epc_pk PRIMARY KEY (nome_entidade,nome_class_extension,ordem_criacao)
)

Através de um pouco de código C#, podemos descobrir se a classe implementada está disponível, instanciá-la dinamicamente e adicioná-la à uma lista de ClassExtensions (propriedade extensions em ICustomClassExtension). Aqui segue um pouco de código para vocês verem a diferença. Dessa forma cada classe cuida só do que ela precisa e podemos compor dinamicamente class extensions poderosas, apenas alterando os registros presentes no banco de dados e contando que os campos manipulados por cada uma exista na feature class.

    public interface ICustomClassExtension:IClassExtension,IObjectClassExtension,IObjectClassEvents,IObjectClassValidation
    {
        List extensions { get; set; }
        void CreateExtensions();
    }

    // esta é a classe mais importante. ela provê toda a funcionalidade
    // básica de buscar o banco de dados e encontrar quem são as extensões para
    // cada feature class e como usá-las
    public class CustomClassExtension:ICustomClassExtension
    {
        public List extensions
        {
            get
            {
                throw new NotImplementedException();
            }
            set
            {
                throw new NotImplementedException();
            }
        }

        public void CreateExtensions()
        {
            // vá ao banco de dados e descubra quem são as class extensions aplicáveis à esta classe
            /*
             * foreach (Record r in Query)
             * {
             *      Type t = Type.GetType(r.ClassExtensionAssemblyName) // ValidateParcelGeometry
             *      extensions.Add(Activator.CreateInstance(t));
             * }
            */
        }

        public void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            foreach (IClassExtension classEx in this.extensions)
            {
                // todas as classes implementam init
                classEx.Init(ClassHelper,ExtensionProperties);
            }
        }

        public void Shutdown()
        {
            foreach (IClassExtension classEx in this.extensions)
            {
                classEx.Shutdown();
            }
        }

        public void OnChange(IObject obj)
        {
            // so vou conseguir iterar sobre as classes que implementam IObjectClassEvents
            foreach (IObjectClassEvents classEvents in this.extensions)
            {
                classEvents.OnChange(obj);
            }
        }

        public void OnCreate(IObject obj)
        {
            // so vou conseguir iterar sobre as classes que implementam IObjectClassEvents
            foreach (IObjectClassEvents classEvents in this.extensions)
            {
                classEvents.OnCreate(obj);
            }
        }

        public void OnDelete(IObject obj)
        {
            // so vou conseguir iterar sobre as classes que implementam IObjectClassEvents
            foreach (IObjectClassEvents classEvents in this.extensions)
            {
                classEvents.OnDelete(obj);
            }
        }

        public string ValidateField(IRow Row, string FieldName)
        {
            string result = String.Empty;
            // so vou conseguir iterar sobre as classes que implementam IObjectClassValidation
            foreach (IObjectClassValidation validation in this.extensions)
            {
                result += validation.ValidateField(Row, FieldName);
            }

            return result;
        }

        public string ValidateRow(IRow Row)
        {
            string result = String.Empty;
            // so vou conseguir iterar sobre as classes que implementam IObjectClassValidation
            foreach (IObjectClassValidation validation in this.extensions)
            {
                result += validation.ValidateRow(Row);
            }

            return result;
        }
    }

    public class ValidateParcelGeometryExtensions : IClassExtension, IObjectClassExtension, IObjectClassValidation
    {
        public void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            throw new NotImplementedException();
        }

        public void Shutdown()
        {
            throw new NotImplementedException();
        }

        public string ValidateField(IRow Row, string FieldName)
        {
            throw new NotImplementedException();
        }

        public string ValidateRow(IRow Row)
        {
            throw new NotImplementedException();
        }
    }

    public class OnParcelEvents : IClassExtension, IObjectClassExtension, IObjectClassEvents
    {
        public void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            throw new NotImplementedException();
        }

        public void Shutdown()
        {
            throw new NotImplementedException();
        }

        public void OnChange(IObject obj)
        {
            throw new NotImplementedException();
        }

        public void OnCreate(IObject obj)
        {
            throw new NotImplementedException();
        }

        public void OnDelete(IObject obj)
        {
            throw new NotImplementedException();
        }
    }

    public class ValidateDwgFile : IClassExtension, IObjectClassExtension, IObjectClassValidation
    {
        public void Init(IClassHelper ClassHelper, ESRI.ArcGIS.esriSystem.IPropertySet ExtensionProperties)
        {
            throw new NotImplementedException();
        }

        public void Shutdown()
        {
            throw new NotImplementedException();
        }

        public string ValidateField(IRow Row, string FieldName)
        {
            throw new NotImplementedException();
        }

        public string ValidateRow(IRow Row)
        {
            throw new NotImplementedException();
        }
    }

As vantagens de algo assim são enormes do ponto de vista de manutenção. São três simples tabelas e uma mudança simples de estrutura de código que vai dar muito mais liberdade para os desenvolvedores e usuários. No momento em que construirmos uma nova extensão, se todos os usuários tiverem à mesma instalada no PC, é só associarmos a mesma à uma entidade que imediatamente deveria funcionar perfeitamente. Poderíamos até deixar à cargo do usuário ligar ou desligar as class extensions de seu interesse.

Entendo que este post é um ArcObjects um pouco mais avançado, mas é muito divertido ver como simples mudanças de arquitetura facilitam a vida dos desenvolvedores e transformar a forma como o usuário se relaciona com o software.

O que acharam?

Um abraço pessoal,

George R. C. Silva

Related posts:

1. Cascading Class Extensions
2. ArcObjects e Class Extensions #1
3. Padrão de Projeto ActiveRecord e ArcObjects

Class Extensions é um assunto relativamente antigo. Quem já desenvolveu para ArcObjects às conhecem razoavelmente bem e são implementadas em larga escala como forma de customização avançada dos famosos geodatabases (qualquer um deles, seja Personal, File ou ArcSDE).

Bem, as class extensions são implementadas através de algumas interfaces especiais e devem ser registradas em uma categoria apropriada (o assunto das categorias de objetos ESRI merece um post sozinho!), GeoObjectClassExtensions para funcionarem e além disso devem ser aplicadas à uma Feature Class ou Table para rodarem apropriadamente. E outra coisa: elas só funcionam com quem possui o código cliente (da Class Extension) instalado na máquina. Para quem não possui o cliente elas se comportam de maneira comum.

Com Class Extensions é possível customizar o inspetor de objetos (aquele carinha utilizado para editar os objetos), customizar a renderização de objetos (isso é poderoso!) e customizar a validação realizada pelo ArcGIS antes da feature receber uma chamada no método Store() (ou seja, antes de ir para o banco);

Existem diversas coisas legais que podemos fazer com estas class extensions e não existe muita dificuldade de implementação (claro, quanto mais requisitos ou quanto mais complexos, mais complicado é de implementar e manter uma CE.).

As CEs podem existes para os seguintes tipos:

• Features
• Rows
• Quaisquer tipos derivados de IRow

O que isto quer dizer? Bem, tanto tabelas, quanto feature classes e qualquer objeto derivado disto podem ter CEs.

Os requerimentos/limitações para Class Extensions são:

• Feature classes e tabelas só podem ter uma class extension;
• A CE precisa ser registrada na categoria apropriada (GeoObjectClassExtensions)
• A funcionalidade não está presente no repositório de dados e sim no cliente. Sempre será necessário realizar o deploy de todo o código das CEs em todos os clientes;

Não são requerimentos/limitações muito pesadas, portanto é uma alternativa viável para customizações mais complexas do procedimento de edição/criação/deleção de objetos.

Obrigatoriamente, o desenvolvedor precisa implementar as seguintes interfaces: IObjectClassExtension (e IFeatureClassExtension, caso seja uma extensão para feature classes). Neste ponto, nossa CE não tem nenhuma funcionalidade. Ela apenas existe.

Para adicionar funcionalidade, podemos implementar outras interfaces, listadas à seguir:

• IObjectClassEvents
• IObjectClassValidation
• IObjectClassInfo
• IRelatedObjectClassEvents
• IConfirmSendRelatedObjectEvents
• IFeatureClassEdit
• IFeatureClassDraw
• IFeatureClassCreation
• IObjectInspector

Estas interfaces são opcionais, cada uma oferencendo um pouquinho de funcionalidade customizada. Hoje falaremos sobre IObjectClassEvents, que é uma das interfaces mais comum de se implementar. Ao longo de uma pequena série tentarei demonstrar a funcionalidade de algumas destas interfaces.

IObjectClassEvents

Esta interface é responsável por nos fornecer métodos para lidar com os eventos de criação, atualização e deleção de um registro. Pense em uma trigger de um banco de dados. Sempre que o evento disparar, determinado método será disparado em sequência.

Os métodos que devem ser implementados para total aderência ao contrato (a interface ) são:

• OnCreate(IObject obj);
• OnChange(IObject obj);
• OnDelete(IObject obj);

Um exemplo de implementação de uma CE com a interface IObjectClassEvents. Note que esta implementação não é completa, ou seja, faltam métodos para o registro da CE, inicialização correta, etc;

Imagine que temos uma tabela log de operação. Nela salvamos os registros relativos às operações realizadas por todos operadores durante o dia. Sua estrutura é a seguinte (em SQL, mas devemos considerar que a tabela está presente em um ambiente ArcGIS - Geodatabases de qualquer tipo);

CREATE TABLE LOG_OPERACAO(
OBJECTID serial NOT NULL,
NOME_TABELA VARCHAR(100) NOT NULL,
NOME_USUARIO VARCHAR(100) NOT NULL,
TIPO_OPERACAO VARCHAR(20) NOT NULL,
OID_ORIGINAL integer NOT NULL,
DATA_HORA_OPERACAO timestamp NOT NULL default now()
CONSTRAINT LOG_OPERACAO_PK PRIMARY KEY (OBJECTID)
);

    public class LogUsuario:IObjectClassExtension,IObjectClassEvents
    {
        public void OnCreate(IObject obj)
        {
            // vamos adicionar um registro à uma tabela de log de operações
            // precisamos de nosso workspace para abrir a tabela
            IFeatureWorkspace workspace = ((IDataset)obj.Class).Workspace;
            ITable logTable = workspace.OpenTable("LOG_OPERACAO");

            // só vamos tentar adicionar se a tabela existir no geodatabase!
            if (logTable != null)
            {
                // ok, a tabela existe. caso não existisse, ela seria nula
                // portanto, vamos criar um novo registro
                IRow novoRegistroLog = logTable.CreateRow();

                novoRegistroLog.set_Value(1,((IDataset)obj.Class).Name); // nome da tabela que estamos modificando
                novoRegistroLog.set_Value(1,Environment.UserName); // nome do usuario
                novoRegistroLog.set_Value(2,"INSERCAO"); // tipo da operacao
                novoRegistroLog.set_Value(3,obj.OID); // id no geodatabase
                novoRegistroLog.set_Value(4,DateTime.Now); // data e hora
                novoRegistroLog.Store();
           }
     }

        public void OnChange(IObject obj)
        {
            // vamos adicionar um registro à uma tabela de log de operações
            // precisamos de nosso workspace para abrir a tabela
            IFeatureWorkspace workspace = ((IDataset)obj.Class).Workspace;
            ITable logTable = workspace.OpenTable("LOG_OPERACAO");

            // só vamos tentar adicionar se a tabela existir no geodatabase!
            if (logTable != null)
            {
                // ok, a tabela existe. caso não existisse, ela seria nula
                // portanto, vamos criar um novo registro
                IRow novoRegistroLog = logTable.CreateRow();

                novoRegistroLog.set_Value(1,((IDataset)obj.Class).Name); // nome da tabela que estamos modificando
                novoRegistroLog.set_Value(1,Environment.UserName); // nome do usuario
                novoRegistroLog.set_Value(2,"ATUALIZACAO"); // tipo da operacao
                novoRegistroLog.set_Value(3,obj.OID); // id no geodatabase
                novoRegistroLog.set_Value(4,DateTime.Now); // data e hora
                novoRegistroLog.Store();
           }
     }

        public void OnDelete(IObject obj)
        {
            // vamos adicionar um registro à uma tabela de log de operações
            // precisamos de nosso workspace para abrir a tabela
            IFeatureWorkspace workspace = ((IDataset)obj.Class).Workspace;
            ITable logTable = workspace.OpenTable("LOG_OPERACAO");

            // só vamos tentar adicionar se a tabela existir no geodatabase!
            if (logTable != null)
            {
                // ok, a tabela existe. caso não existisse, ela seria nula
                // portanto, vamos criar um novo registro
                IRow novoRegistroLog = logTable.CreateRow();

                novoRegistroLog.set_Value(1,((IDataset)obj.Class).Name); // nome da tabela que estamos modificando
                novoRegistroLog.set_Value(1,Environment.UserName); // nome do usuario
                novoRegistroLog.set_Value(2,"INSERCAO"); // tipo da operacao
                novoRegistroLog.set_Value(3,obj.OID); // id no geodatabase
                novoRegistroLog.set_Value(4,DateTime.Now); // data e hora
                novoRegistroLog.Store();
           }
     }
}

Bem, este é um exemplo de implementação da interface IObjectClassEvents. Poderiamos ter deixado o código muito mais limpo (escrevendo uma função à parte para a criação de um registro na tabela de log, por exemplo) e implementado outras funcionalidades. O que importa é que você já sabe como implementar algumas funcionalidades extras dentro do ArcGIS. Lembrando que para esta CE funcionar precisamos aplicar a mesma à uma feature class. Para aplicar uma class extension programaticamente, preciso utilizar algo similar à isto:

public void ChangeClassExtension(IObjectClass objectClass, String extensionUID,IPropertySet extensionProperties)
{
    ISchemaLock schemaLock = (ISchemaLock)objectClass;

    try
    {
        // Attempt to get an exclusive schema lock.
        schemaLock.ChangeSchemaLock(esriSchemaLock.esriExclusiveSchemaLock);

        // Cast the object class to the IClassSchemaEdit2 interface.
        IClassSchemaEdit2 classSchemaEdit = (IClassSchemaEdit2)objectClass;

        if (!extensionUID.Equals(""))
        {
            // Create a unique identifier (UID) object and change the extension.
            UID extUID = new UIDClass();
            extUID.Value = extensionUID;
            classSchemaEdit.AlterClassExtensionCLSID(extUID, extensionProperties);
        }
        else
        {
            // Clear the class extension.
            classSchemaEdit.AlterClassExtensionCLSID(null, null);
        }
    }
    catch (COMException comExc)
    {
        throw new Exception("Could not change class extension.", comExc);
    }
    finally
    {
        schemaLock.ChangeSchemaLock(esriSchemaLock.esriSharedSchemaLock);
    }
}

Este snippet de código tirado da documentação da EDN (ESRI Developer Network), instalado junto com o SDK faz as seguintes operações:

1. Tenta assumir um lock exclusivo sobre a ObjectClass (veja a interface IObjectClass);
2. Converte a object class para um class schema edit (veja IClassSchemaEdit2), para poder acessar os membros (métodos e propriedades) de edição;
3. Acha a extensão através do código GUID (é o carinho que se vê como um atributo de classe, localizado acima da declaração comum de classe, no seu projeto do Visual Studio;
4. Altera a class extension;
5. Libera o lock exclusivo (feito na chamada finally para termos garantia que o lock não ficará por lá, atoa);

O que acharam pessoal? Não é exatamente um bixo de sete cabeças, mas precisamos aprofundar nos ArcObjects para ter sucesso na implementação de class extensions úteis. O exemplo fornecido é bobo, pode ter utilidade, mas existem milhares de possibilidades com esses diabinhos. Vários produtos de nível corporativo (soluções de energia, da Miner&Miner por exemplo), apostam pesado na customização de feature classes como saída para problemas complexos.

Tentem brincar um pouquinho com as class extensions. É bem divertido e rende um trabalho interessante.

Vou ficar por aqui!

Um abraço,

George R. C. Silva

Related posts:

1. ArcObjects e Class Extensions #2
2. Padrão de Projeto ActiveRecord e ArcObjects
3. Cascading Class Extensions

Faz um tempo que não apareço, mas é por um bom motivo. Estou completamente atolado de trabalho e tenho passado a maior parte de meus dias em Manaus. É uma ótima cidade, apesar do calor que vem fazendo e das constantes quedas de energia que sofremos no escritório. Esquenta, ligam mais ar-condicionados, a rede não aguenta e todo mundo fica sem luz e sem ar. É divertido ver como essas coisas funcionam .

Hoje gostaria de falar um pouquinho sobre as dificuldades da integração de produtos CAD com SIGs ou GISs. É um assunto, como sempre, extenso, mas como está me tomando um bocado de tempo, achei que seria bastante apropriado comentar alguma coisa sobre isso.

Gostaria de começar explicitando que o CAD é um excelente programa: para o que ele foi construído. Ele não foi desenvolvido para construção ou armazenamento de feições geográficas. O CAD é um programa de desenho e apenas isso. Ele entende o básico, pontos, linhas, polígonos e anotações. Não tem a menor idéia de semântica. Quando digo semântica, ele não compreende o que cada linha significa ou o que pode ser. O GIS também não é muito esperto neste ponto, mas o número de regras de negócio que podem ser representadas é maior e mais consistente.

Então imaginem, um projeto enorme, que requer que se levante uma área extensa, tudo feito em CAD. O CAD dá produtividade, é mais fácil de arrumar mão de obra, por aí vai. Tudo bem, mas quando chegamos na parte de conversão de dados para o ArcGIS ou qualquer outro software, ficamos em uma saia justíssima. Porque?

• As plantas em CAD em geral são mal construídas. Isto significa que veremos muitos polígonos não fechados, vértices duplicados em uma mesma linha, self-intersections (é quando dentro de um polígono ou uma linha, temos uma auto-inteseção, a geometria se cruza - gerando um erro difícil de detectar e causador de inúmeros problemas, como no cálculo de área);
• Plantas em CAD sempre terão inúmeras versões. Mas muitas mesmo. Não estou falando de três ou quatro. São três ou quatro - por dia. Pelo menos uma por usuário trabalhando na mesma área geográfica.
• Os objetos CAD (pontos, linhas e polígonos) não possuem atributos. É difícil identificá-los unicamente num mar de geometrias. Dependemos unicamente de labels estrategicamente posicionados e milhares de joins espaciais para tentar identificar um objeto corretamente.

Bem, estes são alguns dos problemas que existem em ambientes mistos, mas temos de tolerá-los, correto?

A melhor maneira de lidar com este workflow é a criação de um modelbuilder (quando estamos falando de ArcGIS, claro) ou algum script esperto em Python para cuidar dos detalhes chatos.

Foi o que fizemos, mas outros problemas de gerenciamento de dados e workflow nos deram bastante trabalho. Mas está tudo mudando - existe uma salvação! ArcSDE ao resgate. Apesar do que dizem, que geodatabases são lentos, difíceis de se trabalhar, etc. montamos um mini ambiente em menos de um dia e conseguimos colocar todo mundo trabalhando em cima de uma pequena máquina DELL - que já conseguiu seu próprio no-break e vou pedir mais alguns GB de RAM nesta semana.

Mudou de ambiente, mudou de problema, mas pelo menos é um problema que eu consigo resolver com trabalho de máquina , ao invés de trabalho "braçal".

Até comecei um pequeno novo projeto para ajudar nas (infinitas) correções dos problemas CAD. Estou montando uma pequena extensão do ArcMap para gerenciar usuários e correções, com áreas assinaladas à usuários, prazos, entre outras coisinhas mais para facilitar a (nossa) vida. Por ser um projeto da empresa, não posso comentar, mas vou dando pequenos detalhes assim que possível (o ArcMap já possui uma extensão oficial da ESRI para cuidar disso, é a PLTS - Production Line Tool Set - mas como não preciso de todos os recursos e não tenho tempo ($) para isso, vou criar uma coisinha mais simples).

Bem pessoal, vou nessa. Amanhã é preto na folhinha.

Abraços,

George R. C. Silva

Related posts:

1. ArcObjects #1 – introdução
2. Padrão de Projeto ActiveRecord e ArcObjects
3. ArcObjects e Class Extensions #1

TerraView e Qt 3 no Visual Studio 2003.

Por: Joao Tacio

1. Introdução

Este tutorial tem o objetivo de explicar como configurar o ambiente de

programação para desenvolver aplicações utilizando a IDE Visual Studio 2003,

e as bibliotecas TerraView e Qt 3.

2. Configurar TortoiseCVS para acessar o repositório do TerraLib.

Após instalar o TortoiseCVS, crie uma pasta na raiz do disco principal, por

exemplo TerraDIR e siga os passos abaixo:

• Clique com o botão direito sobre a pasta;

• Escolha SVN Checkout;

• A figura 1 apresenta a janela que vai aparecer.

Figura 1 - Tela de Checkout

Para acessar o repositório do TerraView, é necessário informar a URL of

repository, que deverá ser usado sempre o caminho atualizado no site do

TerraView, na guia Downloads e subitem Fontes (desenvolvedor).

A figura 2 apresenta o endereço acessado no dia 21/05/2010. Este tutorial vai utilizar a versão 3-3-1.

Figura 2 – Endereço para acessar o TerraView

3. Configura a biblioteca Qt.

Qt é uma biblioteca C++ que permite que você possa programar para Windows,

Unix/Linux e Mac, de modo portável, escrevendo o código uma única vez para

esses sistemas. Atualmente essa biblioteca pertence à Nokia. Para maiores

informações consulte o site trolltech.

Crie uma pasta em C:/, com o nome de Qt3 e em seguida baixe a biblioteca

para essa pasta. Para baixar a biblioteca Qt, siga os mesmos passos utilizados

ao obter a biblioteca TerraView porém, em URL of repository, insira o caminho:

https://qtwin.svn.sourceforge.net/svnroot/qtwin/qt-3/trunk ~ 40 MB

4. Variáveis de ambiente

As variáveis de ambiente são criadas a partir da tela de propriedades do sistema. Para exibir essa tela, clique em iniciar/painel de controle/sistema. Escolha a guia avançado e em seguida clique em variáveis de ambiente, conforme é apresentado na figura 3.

Figura 3 – Variáveis de ambiente

A seguir é necessário criar duas variáveis de ambiente (de usuário), QTDIR e QMAKESPEC. A figura 4 ilustra como essas variáveis são configuradas. Atenção o valor da variável QTDIR, deverá ser o diretório do Qt, QMAKESPEC varia conforme o compilador.

Figura 4 – Variáveis QTDIR e QMAKESPEC

Após criar QTDIR e QMAKESPEC, é necessário atualizar a variável Path (de usuário). Clique sobre a variável path, escolha a opção editar e sem seguida adicione ao final a linha (;%QDIR%\bin\), apresentado na figura 5.

Nota: Observe que existe um ponto e vírgula (;) antes da linha %QDIR%\bin\.

Figura 5 – Variável de ambiente Path

5. Realizar um Build da biblioteca Qt.

O compilação (Build) será realizado usando o Prompt de Comando do Visual Studio. Clique em iniciar/programas/Microsoft Visual Studio 2003/Visual Studio Tools/Visual Studio 2003 Command Prompt.

A figura 6 apresenta o Prompt de Comando.

Figura 6 - Prompt de comando do Visual Studio

Na tela do Prompt Command digite os comando abaixo:

• cd\ e pressione Enter;

• cd Qt3 Enter;

• digite configure Enter.

Aguarde todo o Build ser realizado. O tempo aproximado são 30 minutos. Após concluir o Build digite nmake, e aguarde pouco minutos. Para certificar-se que a instalação ocorreu de maneira correta, abra o projeto t1, no endereço C:\Qt3\tutorial\t1\ t1.vcproj. Faça um Build e execute o projeto para aparecer uma tela com um botão escrito Hello Word.

5.1 Atalho para a biblioteca Qt.

Pressione com o botão direito do mouse no arquivo designer.exe, que está em C:\Qt3\bin, escolha enviar para e por fim clique em área de trabalho(criar atalho).

6 Compilando o TerraView

O projeto TerraView no Visual Studio já vem configurado com a seqüência correta que os projetos agregados a ele serão compilados, portanto para compilar o TerraView basta selecionar o menu Build/Rebuild Solution. Caso não por possível compilar o projeto por falta de alguma configuração no Visual Studio, compile os projetos na seguinte ordem abaixo:

• libjpeg;

• tiff;

• shapelib;

• terralib;

• qtw;

• libspl;

• stat;

• terralibpdi;

• terraView.

A figura 7 apresenta a maneira de compilar os projetos separadamente. Clique com o botão direito sobre o projeto, por exemplo: libjpeg e escolha Rebuild.

Figura 7 – Rebuild projeto

6.3 Compilando Plugin no TerraView

Esta sessão apresenta os passos para inserir um plugin personalizado no TerraView. Primeiramente verifique se o plugin HelloWorld está criado no projeto do TerraView. Essa verificação é feita visualizando se existem a pasta HelloWorld, no caminho C:\FullTerraib\terraViewPlugins\HelloWorld. Caso o seu projeto não possua essa pasta, veja com criar os primeiros artifícios para o plugin no tutorial do TerraView 3.3.1 , páginas 3 até 14.

A ferramenta qmake da biblioteca Qt, será usada na criação de um projeto para o Visual Studio, através do arquivo de projeto do plugin (HelloWorld.pro). A figura 9 apresenta como criar o um projeto para o Visual Studio através da tela de Prompt de Comando. Inicie a janela do prompt de comando, através do caminho: iniciar/executar/digite cmd + Enter. No prompt de comando digite C:/Qt3/bin + Enter. Informe o caminho completo do arquivo HelloWorld.pro entre aspas duplas + Enter. Consulte a figura 8, para esclarecer as dúvidas.

Figura 8 – Criar projeto para Visual Studio usando o prompt de comando

O arquivo de projeto para o Visual Studio (HelloWorld.vcproj), será criado após terminar a execução do qmake. Para visualizá-lo, entre na pasta C:\FullTerraib\terraViewPlugins\HelloWorld.

O TerraView carrega os plugin´s que estão dentro da pasta C:\FullTerraib\terraView\windows\plugins. Antes de continuar, verifique que esta pasta não contém arquivos de projetos. O próximo passo é compilar o plugin do Visual Studio. Clique duas vezes sobre o arquivo de projeto HelloWorld.vcproj no diretório C:\FullTerraib\terraViewPlugins\HelloWorld, em seguida selecione o menu Build e escolha a opção Rebuild Solution. Consulte novamente a pasta C:\FullTerraib\terraView\windows\plugins e veja que todo o resultado da compilação do projeto. Pode fechar o Visual Studio.

O plugin HelloWorld já poderá ser visto. Abra novamente a solution do TerraView, no diretório C:\FullTerraib\terraView\windows\ terraView.sln e em seguida clique sobre o menu Build/Rebuild Solution. Assim que terminar o build com sucesso, clique em start debugging e será apresentado o plugin, conforme a figura 9.

Figura 9 – Plugin para TerraView

7 Erros comuns

7.1 Não encontrou qt.lib

Não foi possível encontrar o qt.lib. Clique com o botão direito sobre o projeto que gerou o erro e selecione propriedades para exibir a figura 10.

Figura 10 – Propriedades do projeto

Selecione a tag Linker e escolha input. No lugar de \lib\qt.lib, insira \lib\qt-mt3.lib.

7.2 (...Binary was not built with debug information...)

Clique com o botão direito sobre o projeto TerraView;

Escolha propriedades;

Selecione a guia Configuration Properties/CC++/Optimization

Optimization: escolha Disabled (/Od)

Selecione a guia Linker na guia Configuration Properties/ Linker/Debugging

Debugging Debug Info: escolha Yes (/DEBUG)

7.3 Erro ao compilar projeto qwt

Descrição do erro:

qwt error PRJ0019: A tool returned an error code from "Moc'ing .\..\src\qwt\include\qwt_wheel.h..."

Verifique se as variáveis de ambiente estão corretas

Nome da variável: QTDIR

Valor da variável: Diretório que está o Qt, por exemplo C:\Qt\3.2.0

Nome da variável: QMAKESPEC

Valor da variável: win32-msvc.net (para o compilador visual studio 2003)

Em seguida procure e selecione a variável path.

Nota: Geralmente a variável que necessita ser alterada é a variável de ambiente do sistema, porém já encontrei

algumas máquinas que por algum motivo, é necessário editar a variável de ambiente do usuário.

Para alterar o conteúdo da variável path, clique sobre o botão editar e adicione ao final -> ;%QDIR%\bin\.

Não esqueça do ponto-e-vírgula antes do sinal %.

Após verificar os itens acima, compile o projeto qwt. Casoo erro persista, clique com o botão direito

sobre o projeto qtw, selecione propriedades e faça a configuração abaixo.

Guia C C++/General/Additional Include Directories

..\..\src\qwt\include;"$(QTDIR)\include"

Guia Linker/Input

$(QTDIR)\lib\qt-mt3.lib

Se esse tutorial foi útil, deixe um comentário por favor. Obrigado

Referências

Configurar Qt para Windows. Disponível em http://qtwin.sourceforge.net/qt3-win32/compile-msvc-2005.php. Acesso 21/05/2010.

TortoiseCVS. Disponível em: http://www.tortoisecvs.org. Acesso 18/05/2010.

TerraView. Disponível em: http://www.terralib.org. Acesso 18/05/2010.

Trolltec. Disponível em: hhttp://www.trolltech.com. Acesso 18/05/2010.

Visual Studio. Disponível em: http://social.msdn.microsoft.com 11-06. Acesso 15/05/2010.

Construindo um Plugin - TerraView 3.3.1. Disponível em http://www.dpi.inpe.br/terraview/php/plugins.php. Acesso 11/05/2010.

Joao Tacio/TerraLab/UFOP-MG

Related posts:

1. Conheça melhor o TerraView
2. Configure o TerraLib no Visual Studio 2003
3. Hello World, ArcGIS style!