Arquivo da tag: arcgis

Funções Geoespaciais do MS SQL Server 2008

Deixe um comentário

O MS SQL Server 2008 (MSSQL) possui um tipo próprio para guardar geometrias: geometry (tem um geography também, mais útil para representar feições mais extensas).

E ainda implementa os métodos definidos pela OGC.

Isto possibilita operações CRUD sobre o dados georreferenciados, diretamente através de comandos SQL.

Os métodos estáticos, acessíveis através de geometry::NomeDoMétodo(),  são:

E os métodos do objeto geometry:

Estes métodos podem ser chamados da seguinte forma, por exemplo:


SELECT coluna1.STArea() FROM tabela

onde coluna1 é do tipo geometry.

Inserindo registros geoespaciais: ArcSDE e SQL Server

Deixe um comentário

Inserir registros diretamente através de comandos SQL é bem simples. Note que estou usando como tipo de dado geoespacial o GEOMETRY, nativo do SQL Server 2008.

Primeiro  é necessário criar uma tabela no SQL Server e registrá-la junto ao ArcSDE. Isto é bem simples de se realizar utilizando o ArcCatalog (note que também dá para se criar a tabela via SQL e registrá-la no ArcSDE via linha de comando).  Basta entrar no ArcCatalog, conectar-se com sua instância do ArcSDE e clicar com o botão direito no ícone do banco de dados. Depois é só escolher o Feature Class:

Feature Class

Criando um Feature Class

É apresentada então uma caixa de diálogo para criar sua tabela que conterá sua feição. Criei uma tabela chamada MeuFeatureClass. As colunas OBJECTID e SHAPE são criadas por padrão. Adicionei um campo1 e um campo2 também. E escolhi o tipo da geometria como POINT.

Criada a tabela é bem simples de se inserir um registro através de comando SQL:

INSERT INTO
MeuBD.sde.MeuFeatureClass
(OBJECTID, campo1, campo2, shape)
VALUES
(1, valor1, valor2, geometry::STGeomFromText('POINT (-46.616667 -23.533333)', 4674))

O comando acima insere um registro na tabela contendo um ponto localizado no município de São Paulo – SP, usando o SRID 4674 (SIRGAS 2000).

Note que não usamos uma função típica do T-SQL  para transformar o texto dado em uma coordenada válida pro sistema.  Isto me deixou confuso no início, pois eu não encontrava funções geoespaciais no banco de dados. Liste as funções existentes no banco de dados do ArcSDE que oê não encontrará nada relacionado ao sistema geo.

Estas funções ficam disponíveis como métodos da classe e objetos  geometry.  No caso acima, o STGeomFromText é um método estático da classe geometry. Os mundos da Orientação a Objetos e do SQL se mesclam cada vez mais…

Cache e camadas no ArcGIS Server

Deixe um comentário

Estou trabalhando com o ArcGIS Server 9.3.1 e tenho de inserir alguns serviços nele. Cada serviço corresponde à uma camada, ou  layer, em meu mapa.

Para melhorar o  desempenho – sofrível se comparado com o MapServer – existe uma opção para a utilização de cache no ArcGIS Server que funciona bem. Ao invés do servidor ter de reconstruir a imagem, toda vez que ela é requisitada, ele gera esta imagem apenas uma vez, grava em algum lugar e depois apenas a repassa para o servidor de aplicação.

Isto gerou um problema. Quando as imagens era geradas dinamicamente, havia a possibilidade do ArcGIS Server reprojetar e/ou reposicionar o mapa para  combiná-la com todos os layers.  Se um serviço usa EPSG:4618 e outro usa SR-ORG:95,  por exemplo. Mas com o uso do cache, a imagem criada possui apenas o sistema de referenciamento definida no serviço, não podendo mudar.

Assim, ao combinar dois layers cujos sistemas de referenciamento espacial são diferentes, temos as seguintes situações:

  • Os dois layers são dinâmicos:  um sistema é escolhido e os dois layers utilizam este;
  • Um dos layers é dinâmico e o outro possui cache: o dinâmico é projetado/adaptado ao sistema do que tem cache;
  • Os dois layers usam cache: apenas um deles é exibido. Não há reprojeção.

O ideal então é manter um único sistema de referenciamento espacial nos serviços. E aproveitar para deixar todos no SIRGAS2000.

ArcGIS Javascript, Dojo e o método require

1 resposta

Ando investigando a API Javascript ArcGIS. Esta API é escrita em cima do framework Dojo, que provê um monte de funções úteis, além de um biblioteca bacana de widgets.

Tentando criar um código JS mais organizado, encontrei o método dojo.require, que, em conjunto dos métodos dojo.declare e dojo.provide, devolvem um pouco de sanidade ao programandor.  Ele funciona da seguinte maneira.  Você inventa um namespace/pacote,  e depois associa um caminho à ele:

dojo.registerModulePath( "pacote", "http://localhost/scripts/")

E depois pode incluir ou importar pacotes assim:

dojo.require("pacote.MinhaClasse");

A mágica é que o arquivo http://localhost/scripts/MinhaClasse.js é carregado automaticamente. Legal! Parecido com Java, C# e um monte de outras linguagens. Agora vou criar arquivos correspondentes às classes que criarei, e organizar a macarronada Javascript.

Mas não. A API Javascript ArcGIS, por alguma razão, procura pelo arquivo http://localhost/scripts/MinhaClasse.xd.js !!! De onde saiu este xd? E mesmo criando o arquivo que ele espera, seu conteúdo não é processado da forma correta.

Elaborando alguns testes eu susbtitui a referência:

<script type=”text/javascript” src=”http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1.4″></script>

pela:

<script type=”text/javascript” src=”http://dojotoolkit.org/sites/all/modules/dojo/dtk_build/dojo/dojo.js”></script>

E funcionou ok. Parece que a versão do dojo entregue pela ESRI no ArcGIS não permite o uso do dojo.require. Para que isto seja possível, é necessário compilar o dojo de forma a permiti-lo carregar arquivos de domínios distintos, ou cross domain. Mas na API da ESRI não dá. Pena.

Encontrei como resolver o problema:

        djConfig = {
            parseOnLoad: true,
            baseUrl: "./scripts",
            modulePaths: {
                "minhasClasses": "./minhasClasses",
                "meusDijits": "./BLA"
            },
           isDebug: true
        }

Isto me ensina a aprender direito antes de escrever! =)