Diquinhas de ArcGIS #2
Novas diquinhas frescas para você!
Boa tarde pessoal, uma coisa legal que o ArcMap tem de MONTE são atalhos. Atalhos, são...atalhos. Faça o que você precisa fazer, mas mais rápido. Isso não é bom? Ah, estas dicas são para versão 9.3.1;
Portanto, hoje vou falar de alguns, pois existem muitos:
Atalhos comuns à todas as ferramentas de edição
- Z (Zoom Mais);
- X (Zoom Menos);
- C (Navegação);
- B (Navegação contínua);
- V (Mostrar vértices);
- Esc (Cancela operação);
- Ctrl+Z (desfazer);
- Ctrl+Y (refazer);
- Segurar Barra de Espaço (suspende snapping);
Os mais demais são os em negrito. Mãozassa na roda.
Post de hoje foi patrocinado por The Prodigy e Sublime.
Abraços
George R. C. Silva
Diquinhas de ArcGIS #1
Olá pessoal,
Bem vindos ao primeiro post da (espero que longa) série de dicas de ArcGIS. O objetivo é mostrar algo que salva a vida do peão em pouco tempo.
Hoje vamos falar de uma opção bem escondida do Editor que força ao usuário inserir os dados em uma nova feição antes que o ArcGIS a crie de verdade.
O fluxo comum é:
- Criar feição;
- Feição vai para o banco de dados (ou shapefile);
- Editar atributos;
Desta forma, podemos esquecer alguma coisa, ou se existirem campos que são obrigatórios, mas não tem valor default, causar um erro.
No ArcMap é possível pedir para "promptar" o usuário antes de armazenar a feição em nosso repositório de dados
O fluxo alternativo, portanto:
- Criar feição;
- Receber entrada de dados básica;
- Feição vai para o banco de dados (ou shapefile);
Perceba que a entrada de dados foi realizada anteriormente à ida da feição ao banco de dados. Isto ajuda a economizar até um cadinho de banda.
Para habilitar:
Editor > Options > Aba Attributes
Agora é só editar!
É bastante útil em projetos de edição em que se precisa estar atento o tempo todo.
Post de hoje patrocinado por Velhas Virgens e The Offspring.
Abraços
George R. C. Silva
ArcGIS Online recebe grande atualização
Boa tarde pessoal,
Pegando o embalo da ESRI User Conference que está sendo realizada esta semana, em San Diego, o site ArcGIS Online recebeu uma grande atualização de funcionalidades.
Agora é possível construir seus mapas utilizando webservices WMS, renomear camadas, importar KMLs e outras delícias mais. Estas eram funcionalidades há muito esperadas!
Para quem não sabe, ArcGIS Online é uma plataforma na web, que permite que o usuário envie seus dados ou colete dados de outros usuários para montar mapas e mini-SIGs de maneira extremamente fácil e intuitiva. E o melhor, seu mapa pode ser compartilhado com usuários, clientes, etc. É uma plataforma amigável para publicação de informações geográficas.
Nunca testou? Corra até o site e teste! Acredito que ficarão surpreendidos.
Abraços,
George R. C. Silva
Cascading Class Extensions
Olá pessoal, este aqui é um post com mais substância que os outros.
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
Padrão de Projeto ActiveRecord e ArcObjects
Boa noite pessoal!
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:
-
Construímos uma query vazia (equivalente à “SELECT * FROM TABLE”);
-
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);
-
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);
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
ArcObjects e Class Extensions #2
Boa tarde pessoal,
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
ArcObjects e Class Extensions #1
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:
- Tenta assumir um lock exclusivo sobre a ObjectClass (veja a interface IObjectClass);
- Converte a object class para um class schema edit (veja IClassSchemaEdit2), para poder acessar os membros (métodos e propriedades) de edição;
- 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;
- Altera a class extension;
- 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
Integração CAD/GIS
Boa noite pessoal,
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
ArcGIS 10 disponível para venda
Boa noite pessoal!
O ArcGIS 10 finalmente foi lançado para venda oficialmente durante esta semana. Nos Estados Unidos, pelo menos.
O novo ArcGIS promete muita coisa, ArcCatalog integrado com ArcMap, capacidade de edição em três dimensões (dentro do ArcMap!), entre outras coisinhas bastante interessantes.
Temos agora uma nova API para programação em Python, a ArcPy, que pelo visto é bastante poderosa. Criaram novas classes, interfaces e funcionalidades, incluindo a capacidade de automatizar a produção de mapas com Python - o que é uma excelente notícia.
A ESRI já até mudou a cara do site deles para o anúncio. Aqui temos um link com as novas funcionalidades.
George
Brincando com ArcObjects
Boa tarde pessoal,
ArcObjects é algo relativamente difícil. É complicado pois temos muitas formas de se fazer o que queremos, a documentação - apesar de razoável, não é excelente (existem detalhes importantes que podem estar escondidos em outras páginas) e não existe uma comunidade forte que trate destas questões.
Gostaria de mostrar um pouco de ArcObjects aos iniciantes, em especial um namespace complicadinho: ESRI.ArcGIS.Geometry. Não tenho domínio do namespace suficiente para dizer que sou um expert, mas consigo me virar.
O namespace Geometry é o responsável por cuidar de todas as operações com as geometrias, sejam elas de quaisquer tipos. Primeiramente gostaria de apresentaar à vocês aos tipos de geometria de alto-nível. Isto é importante pois algumas funções ou interfaces, só estão disponíveis nas geometrias de alto nível, outras somente nas de baixo nível.
Todas as geometrias de alto nível tem à sua disposição um set teórico de operações possíveis, tais como interseção, união, diferença, diferença simétrica, entre outros. Outras interfaces/classes do namespace ESRI.ArcGIS.Geometry são responsáveis por estas operações.
Geometrias de Alto Nível
As geometrias de alto nível são:
- Points;
- Multipoints;
- Polylines;
- Polygons;
- MultiPatches;
Ponto é o tipo de geometria mais simples que podemos encontrar no modelo do ArcGIS. É basicamente composta de uma coordenada X e uma coordenada Y. Opcionalmente os pontos podem ser IdAware, ZAware e MAware, ou seja: podem ter um Id, Z e M. Todas os tipos de geometrias podem ter estes atributos em seus vértices, que em suma, são pontos.
Multipontos é um tipo de geometria representado por uma coleção de pontos. Da mesma maneira que um ponto, cada ponto desta única geometria tem seus atributos.
Polilinhas são composta pela união de diversos paths (uma geometria de nível mais baixo) que são compostos por sua vez de diversos segments, que podem ser dos tipos: linha, arco circular, curva bezier ou arco elíptico.
Polígonos são geometrias compostas por rings, que são compostos por segments, dos tipos citados acima. A ordem de cada ring e o sentido de construção (horário/ante-horário) determinar o comportamento de cada ring. Exemplo: todos os rings externos são ordenados em sentido horário, indicando que o interior dele é o polígono. Caso um ring seja ordenado em anti-horário você está dizendo ao ArcGIS que ele é hole - com área negativa.
No caso dos polígonos, isso pode ocorrer indefinidamente, sendo determinado pela ordem em que cada ring aparece na coleção.
Multipatches são geometrias compostas e são em três dimensões. São geometrias que podem ter múltiplas superfícies, com textura. É a forma como o ArcGIS representa objetos em três dimensões. São compostas de Triangles, TriangleStrips e TriangleFans.
Todas as geometrias de nível mais baixo são construídas necessáriamente por pontos. É o bloco de construção do ArcGIS.
Geometrias de Baixo Nível
- Paths
- Rings
- Segments
- TriangleStrips
- TriangleFans
- Triangles
Pela estrutura que temos aí dá pra entender melhor não?
Vamos começar brincando com os pontinhos, já que são as estruturas básicas de trabalho.
Classes e Interfaces
Para simplificar para os iniciantes, classe é um projeto de um objeto. Quando criamos um novo, aquele projeto é "materializado" na memória do computador.
Interface é um contrato. Quando dizemos que uma classe implementa uma interface, queremos dizer que aquela classe assinou um contrato de funcionalidade com aquela interface - ou seja, tudo que realiza operações na interface ou em algum membro da interface, está também disponível na classe, sendo possível utilizar aquela classe em alguma função que requer a interface.
PointClass
Esta classe implementa diversas interfaces (ou contratos) do namespace Geometry. As interfaces definem as funcionalidades que a PointClass terá. Caso você tenha o Help de desenvolvimento do ArcGIS instalado, abra o mesmo e procure esta URL ms-help://ESRI.EDNv9.3/esriGeometry/html/Point.htm .
Caso não tenha o help instalado
Como criamos um novo ponto? É bem simples, vejam só.
IPoint ponto = new PointClass();
ponto.PutCoords(10,10);
Vamos criar uma novo projeto C# do tipo ArcGIS>Console Application. Adicione as referências:
- ESRI.ArcGIS.Geometry;
- ESRI.ArcGIS.Framework;
- ESRI.ArcGIS.esriSystem;
Você verá que o Visual Studio já criou algumas linhas código para nós. Este é o código para buscar a licença na máquina. Em qualquer tipo de aplicação que você for construir, você deve ter um código similar para buscar uma licença, senão ele é automaticamente desligado.
namespace DesktopConsoleApplication1
{
class Program
{
private static LicenseInitializer m_AOLicenseInitializer = new DesktopConsoleApplication1.LicenseInitializer();
[STAThread()]
static void Main(string[] args)
{
//ESRI License Initializer generated code.
m_AOLicenseInitializer.InitializeApplication(new esriLicenseProductCode[] { esriLicenseProductCode.esriLicenseProductCodeArcView },
new esriLicenseExtensionCode[] { });
//ESRI License Initializer generated code.
//Do not make any call to ArcObjects after ShutDownApplication()
m_AOLicenseInitializer.ShutdownApplication();
}
}
}
Este é como meu código se parece. O método Main é o que executa o programa de verdade. Para demonstrar o funcionamento da interface IPoint e da PointClass, vamos escrever algo bem simples, para ilustrar.
Acima do namespace, adicione as seguintes linhas:
using ESRI.ArcGIS.Geometry; using ESRI.ArcGIS.Framework;
Elas são necessárias para utilizarmos os objetos contidos nestes namespaces sem qualificá-los totalmente, ex: ESRI.ArcGIS.Geometry.IPoint. Após a adição destas linhas, podemos utilizar somente IPoint, diretamente, pois estes objetos estão à nossa disposição.
Crie um novo método dentro desta classe (isto não é o ideal em código de produção - estude orientação à objetos. este é apenas um exemplo) chamado BuildPoint. Este método deve ser estático (não queremos ter de criar uma outra classe Program para acessá-lo), ou seja, pode ser acessado no "projeto" da classe (ao invés de funcionar no objeto). Neste método, queremos construir um ponto, designar suas coordenadas x, y e z e queremos que esta função nos devolva este ponto.
Ficaria assim:
static IPoint BuildPoint(double x, double y, double z)
{
IPoint ponto = new PointClass();
ponto.PutCoords(x, y);
ponto.Z = z;
return ponto;
}
Sugiro que você não façam somente um Ctrl-C + Ctrl-V dos códigos. Teste isto no Visual Studio. O Intelllisense irá lhe mostrar algumas outras coisinhas interessantes. Não esqueça de consultar a documentação para saber mais sobre cada um dos membros e métodos.
Bem, o que este método faz? Ele simplesmente instancia um novo ponto, atualiza as coordenadas conformes passadas nos argumentos da função e nos devolve o ponto. Para que fazer uma função assim? Bem, são somente 4 linhas de código, mas imagine se você precisa criar 80000 pontos? Certo, então temos nossa primeira função pronta.
O que faremos com ela? Vamos modificar nosso método Main, para ler diversas coordenadas e criar um monte de pontos para nós. Depois iremos pedir para nosso método Main nos mostrar os pontos criados. Além de modificar o Main, vamos construir um segundo método para nos ajudar a criar os pontos.
Vamos lá:
[STAThread()]
static void Main(string[] args)
{
//ESRI License Initializer generated code.
m_AOLicenseInitializer.InitializeApplication(new esriLicenseProductCode[] { esriLicenseProductCode.esriLicenseProductCodeArcView },
new esriLicenseExtensionCode[] { });
//ESRI License Initializer generated code.
//Do not make any call to ArcObjects after ShutDownApplication()
m_AOLicenseInitializer.ShutdownApplication();
// após a inicialização da licença, vamos brincar
string finaliza = "s";
string leitura;
// aqui guardaremos nossos pontos
List listaDePontos = new List();
// enquanto finaliza for diferente de n, repita:
while (finaliza.Substring(0,1).ToLower() != "n")
{
// vamos dizer ao usuário o que precisamos.
Console.WriteLine("Digite as coordenadas de seu ponto. Utilize vírgulas para separá-las");
Console.WriteLine("X,Y,Z");
// leitura guardará o resultado que nosso usuário digitar!
leitura = Console.ReadLine();
// temos uma string. precisamos de um método para quebrá-la
// e nos devolver um ponto - que será inserido na listaDePontos
listaDePontos.Add(TraduzirStringPonto(leitura));
// será que o usuário quer digitar mais pontos?
Console.WriteLine("Você deseja criar mais pontos? n para não");
// vamos alterar o valor de finaliza, que será testa mais à frente.
// note que esta rotina não cobre TODAS AS POSSIBILIDADES
finaliza = Console.ReadLine();
}
// agora que o usuário terminou de criar seus pontos,
// vamos mostrá-los à ele.
Console.WriteLine();
Console.WriteLine("Lista de Pontos:\n");
// para cada variável do tipo IPoint em listaDePontos, faça
foreach (IPoint p in listaDePontos)
{
// \t é caractere de tabulação.
Console.Write("ID " + p.ID.ToString() + "\t");
Console.Write("X " + p.X.ToString() + "\t");
Console.Write("Y " + p.Y.ToString() + "\t");
Console.Write("Z " + p.Z.ToString() + "\t");
Console.WriteLine();
}
// vamos esperar o usuário ler os dados e assim que ele teclar denovo
// finalizamos o programa
Console.WriteLine();
Console.WriteLine("Aperte qualquer botão do teclado para finalizar...");
Console.ReadLine();
}
No meio da função está a lógica do programa. Queremos ler dados, até o usuário dizer não. Note que este programa é bastante simples, não realiza verificação de erros nem os trata. Não deve ser feito assim na vida real!
Mostramos para o usuário algumas propriedades da classse IPoint, algumas setadas por nós, outras não. Viram que todos os IDs são iguais à zero?
Agora vou lhes mostrar a função TraduzirStringPonto. Ela envolve mais programação comum, do que ArcObjects. Vou mostrá-la só para não ficarem no escuro
static IPoint TraduzirStringPonto(string s)
{
// recebemos nesta função uma string e queremos transformá-la em números
// vamos usar o método Split, que tem como argumentos um array de caracteres
// delimitados como as strings, com a exceção de que usamos aspas simples!
string[] arrayDeStrings = s.Split(new Char[]{','},3);
// vamos criar uma array com três posições para receber nossos números!
double[] arrayDeDoubles = new double[3];
// para i = 0 até i = 2
for(int i = 0; i <= 2; i++)
{
// assinale o valor da posição i em arrayDeDoubles
// para ser igual ao valor da posição i em arrayDeStrings,
// convertendo-os para um objeto do tipo Double
arrayDeDoubles[i] = Double.Parse(arrayDeStrings[i]);
}
// vamos criar nosso ponto. lembra de BuildPoint?
IPoint ponto = BuildPoint(arrayDeDoubles[0],arrayDeDoubles[1],arrayDeDoubles[2]);
// nos devolva nosso ponto para que possamos inseri-lo na lista
return ponto;
}
Novamente um aviso: esta função também não tem identificação de erros ou tratamento dos mesmos. Recomendo ao interessado em desenvolver seu método de validação da entrada de dados, pois se inserirmos em nosso programa os valores:
10,eitcha,100
ele irá simplesmente travar - no momento da conversão de string para double.
Esta foi uma gentil introdução à manipulação de geometrias em ArcObjects. Os próximos passos são um pouco mais cabeludos, mas nada que seja impossível.
O que acharam?



