Como posso implementar a API REST ESRI?


Respostas:



8

Acabei de usar o link que Jason postou acima. Não consigo imaginar quando for lançado, as especificações oficiais serão muito diferentes. Era principalmente uma tarefa de enrolar as mangas, acionar o Fiddler, atingir os servidores de amostra 10.0 e começar a invadir a implementação. Não há nada impossível, apenas um tédio com muitos pequenos problemas a serem levados em conta. Nós nem sequer tornamos o nosso 100% compatível, mas ele cobre 85% e todas as APIs do cliente parecem funcionar muito bem (esse foi o único motivo pelo qual o fiz).

aqui está um catálogo de demonstração (muitos bichinhos aqui :) [bFlood - link antigo removido]

estamos rodando no AppEngine (python) e está bastante acoplado às estruturas espaciais subjacentes, mas provavelmente pode ser transformado em um projeto .Net WCF decente. Ainda não sei como distribuí-lo

brian brian

Atualização - 8/3/12 - Acabei de ver esta postagem aparecer na stackexchange e achei que atualizaria o conteúdo. Você pode ter o FeatureService em questão de minutos se experimentar a versão beta do Arc2Earth Sync. o back-end funciona com o Google Fusion Tables e o CartoDB, mas em breve daremos suporte a outros fornecedores. Você não precisa de nada, exceto o ArcView 9.2 ou superior ...

aqui está uma postagem de blog mostrando como começar a coletar dados de campo em minutos usando os aplicativos móveis do ArcGIS.com: http://www.arc2earth.com/2012/03/arc2earth-sync-live-mobile-data-collection-in-5 -minutos/


2
Brian Flood? Kirk Kuykendall? É como se toda a banda dos fóruns da ESRI estivesse novamente reunida!
Sebastian Good

Ei Brian, ótimo ouvir você. Espero que a recompensa atraia alguém a fazer exatamente o que você e Jason descrevem e publique seus resultados em algum lugar como o codeplex. Se não, talvez eu dê um jeito nisso. @ Sebastian, que bom vê-lo aqui também!
22410 Kirk Kuykendall

2
@kirk - sim, eu esperaria que um projeto comunitário fosse iniciado em algum momento. Ele precisaria ser flexível o suficiente para permitir vários back-end espaciais, provavelmente uma arquitetura de plug-in para conectar qualquer versão de provedor de mapas / camadas / recursos (por exemplo, sql azure, postgis, geoserver, mapguide etc.) @Sebastian - sim, fóruns ESRI com pesquisa que realmente funciona. Felicidades!
bFlood

7

A única documentação que eu conheço para a API REST da esri está em sua ajuda online aqui:

http://help.arcgis.com/EN/arcgisserver/10.0/apis/rest/index.html

Isso é escrito mais da perspectiva de um consumidor do que de um provedor, mas deve ser hackável.

Há partes dessa API que são bastante proprietárias (alguns dos formatos de saída ) e impossíveis de serem implementadas por um projeto de código aberto, a menos que essas especificações de formato também sejam disponibilizadas.

Além disso, algumas das APIs REST não são especialmente RESTful. Por exemplo, veja o Feature Service. Parece haver "pontos de extremidade" separados para adicionar / atualizar / excluir / consultar, em vez de usar verbos HTTP padrão para operar com recursos. Isso me intriga; Eu sei que a esri tem pessoas muito inteligentes lá que entendem o REST. Meu palpite é que essas chamadas são mapeadas para algum tipo de interface SOAP, e a esri achou que seria mais fácil para eles e seus clientes se mantivessem a consistência entre elas.

Minha opinião? Se você está apenas procurando compartilhar dados (não configuração de mapa, metadados, etc.) e não está com pressa, é melhor esperar até que a Microsoft descubra como eles vão representar os tipos de dados espaciais no EDM. Com isso, você pode facilmente criar acesso verdadeiramente RESTful às suas tabelas espaciais usando OData e, provavelmente, OData habilitado para RIA. Isso pode ser uma torta no céu, pelo que sei.


Obrigado Jason. Esse é um bom argumento sobre os formatos proprietários de saída. Primeira passagem, eu só quero json, html e imagem. Idealmente, o que eu gostaria é de um projeto C # que usa o WCF WebHttp Services no .NET 4 para buscar dados do Sql Server 2008 e retornar em um formato que qualquer SDK da Web da ESRI possa digerir.
26910 Kirk Kuykendall

Ah, desculpe sim. Eu perdi o subtexto que você estava procurando para atender o software cliente da esri. Absolutamente faz sentido tentar implementar a API nesse caso
JasonBirch

2

Você está pensando em expor tabelas espaciais do SQL Server 2008 Spatial? O ESRI MapIt já faz isso e acredito que o licenciamento permita que aqueles com AGS tenham acesso ao ESRI MapIt.

Algumas telas de como isso pode ser encontrado podem ser encontradas no meu blog: http://geo.geek.nz/development/hiding-databases-from-unauthorised-users-when-using-esri-mapit/

Não há necessidade de escrever alguma coisa? ;)

Felicidades


Hey Jithen, o Serviço de Dados Espaciais discutido neste PDF ( esri.com/library/brochures/pdfs/esri-mapit.pdf ) usando a API REST ESRI, serviços WCF ou algo completamente diferente? Suponho que o MapIt não é gratuito se você não estiver executando o AGS; nesse caso, seria benéfico para a comunidade desenvolver algo que expusesse a API REST ESRI diretamente do MS SQL Server Spatial sem custo adicional, especialmente para aplicativos pequenos que poderiam executar o SQL Express.
31410 JasonBirch

Oi Jithen - Eu baixei a versão de avaliação do MapIT na 1.0 e naquele momento eu precisava instalá-lo na mesma máquina em que o IIS está sendo executado. Meu ISP não permite isso. Também não consegui executar o MapIT em um servidor de desenvolvimento e implantar o site em um servidor de produção - ele deve ser executado no servidor de produção. Talvez isso tenha mudado?
Kirk Kuykendall

11
@JasonBirch Olá Jason, O SDS é uma implementação separada da API REST, mas fornece uma interface semelhante, oferecendo a capacidade de executar consultas no SQL Server Spatial. Um exemplo de consulta: servername / SDS / database / sandbox / dbo.PostcodeBoundaries /… A resposta pode ser lida por qualquer uma das APIs. O ESRI MapIt possui vários recursos importantes e úteis. Por exemplo, projeção on-the-fly e carregador de dados que não vale a pena escrever.
jiriteach

Olá Kirk, 1.1. inclui uma série de novos recursos que são principalmente aprimoramentos para o carregador, mas também a capacidade de implantar facilmente o SDS. O suporte do Azure agora também está incluído. O MapIt só precisa do IIS e da capacidade de conversar com seu SQL Server. Na verdade, é muito fácil de configurar e executar, mas, como mencionado, é a capacidade de implantar no azure agora com uma interface sem cabeça, portanto isso pode ajudá-lo. Cheers
jiriteach

2

Eu já fiz isso em um aplicativo. Não implementei completamente a API REST completa, mas o suficiente para obter uma tarefa de consulta para executar e formatar o JSON corretamente. Eu usei o ASP .NET MVC para criar meu endpoint. Tentei fazer isso há cerca de um ano com o WCF e a saída JSON não foi formatada de maneira a funcionar. O truque com o MVC é garantir que você tenha um resultado JSONP que puxe o parâmetro de consulta de retorno de chamada e faça a resposta jsonp correta. Vou tentar postar algo. Você pode dar uma olhada na resposta aqui:

http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents/query?f=json&where=1%3D1&returnGeometry=true&spatialRel=esriSpatialRelIntersects&outFields= * & outSR = 4326 & callback = dojo.all.script.json_json.io.script.json.io.

No entanto, apenas o parâmetro de retorno de chamada é usado:

http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents?callback=woot

Edit: Aqui está como implementar um resultado JSONP no ASP .NET MVC

/programming/758879/asp-net-mvc-returning-jsonp

Edit # 2: Aqui está um exemplo de código que eu rapidamente criei e coloquei no dropbox.

http://dl.dropbox.com/u/28924446/EsriGeoServicesExampleMvc3.zip


1

Parece que você pode acabar substituindo a funcionalidade do ArcGIS fazendo isso. Eu recomendaria a utilização de um projeto de código aberto existente para implementar esse sistema, se houver um disponível que suporte essa API, talvez escreva seu próprio adaptador para um projeto de código aberto. Talvez exista, mas ainda não pareci muito. Não tenho certeza se eles lançaram uma especificação completa da API ainda, mas se você estiver com pressa, poderá usar a documentação da API existente e testar sua implementação em relação ao software ESRI existente.


Obrigado Dandy, acho que eventualmente haverá um projeto de código aberto. Acho estranho que a ESRI o anuncie, mas não forneça um link para as especificações. Nem tenho certeza de como seria uma especificação da API REST. Apenas um exemplo de uma especificação, juntamente com uma amostra de código, mostrando como alguém a implementaria (com o .NET), seria útil.
21410 Kirk Kuykendall

Lembro-me de algum hype que estava se espalhando para o sistema FGDB sendo aberto, mas acho que eles apenas abriram uma API de código para ele em vez de publicar uma especificação. Eu não teria muitas esperanças, mas você deve ser capaz de implementar algo facilmente usando a documentação do consumidor, como o @JasonBirch também disse.
Dandy



-1

@ JasonBirch - acho que o principal atrativo para fazer isso é a capacidade de integrar-se com esri apps / apis / arcgis.com. Se a esri puxar o plugue usando-os barato (grátis), isso se tornará muito menos importante. Não está claro para mim o que eles planejam fazer com o ArcGIS.com e até como ele é licenciado no momento. Eu o via como um local central para dados / serviços onde aplicativos da web podiam ser registrados, algo como uma loja de aplicativos para dados esri. Terceiros registram aplicativos da web (nuvem) com vários inquilinos, a esri diminui e seu aplicativo fica instantaneamente disponível para todos os compradores compatíveis com as demais especificações da API. Nesse sentido, faz sentido abrir a API restante e permitir a integração do maior número possível de serviços com o hub. a pesquisa / armazenamento de dados geoespaciais está rapidamente a caminho de ser comoditizada, então mova-o um pouco mais e tente controlar o espaço do aplicativo.

Eu acho que o seu comentário OData tem mérito, mas IMO, isso é um caminho. e, o que é mais importante, sem um aplicativo cliente amplamente distribuído e amado (algo como Google Earth), qualquer especificação bem escrita tem o potencial de definhar. Sem dizer que é o caso do OData, existem muitos desenvolvedores de MS por aí que conseguirão instalar isso gratuitamente no VS, mas não o vejo no curto prazo. meus 2 centavos ...

(btw, parece haver um comprimento de comentário bastante curto, portanto, a nova resposta)


11
Sim, este site foi intencionalmente projetado para evitar discussões :) FYI, Haris e eu estamos trabalhando para que o OData trabalhe com o GeoREST (ele está trabalhando, estou incomodando. Geometria em strings com atributo estendido indicando o tipo (KML / GML / GeoJSON).
JasonBirch

isso parece realmente interessante, existe alguma informação online?
bFlood

ainda não, mas gostaria de conversar sobre isso. Nós over-pensei que várias vezes já :) BTW, se incluir o meu @username, recebo notificações de resposta :)
JasonBirch

ahhh, ok @JasonBirch é (deveria ter adivinhado isso). Definitivamente, vamos conversar, eu adoraria desligar o suporte do OData nas nuvens A2E (desde que exista um método sensato para lidar com a geometria, mas agora que eu sei que você e haris estão no caso, estamos todos bem!)
bFlood
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.