A ESRI anunciou que está lançando a API ArcGIS REST como tecnologia aberta . Eu tenho um ISP executando o Sql Server 2008 com IIS7.
Alguém sabe de uma boa maneira de mostrar como eu posso escrever C # usando o WCF para expor tabelas espaciais compatíveis com uma especificação específica (idealmente ESRI)?
Alguém sabe onde estão as especificações da ESRI?
Respostas:
Parece que a ESRI acaba de lançar sua especificação REST GeoServices . Eu acredito que é isso que você pode estar procurando.
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/
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.
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
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
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.
aqui está um exemplo: http://www.arcgis.com/home/item.html?id=6d28a606369c43fd9a6f929541ae7c93
@ 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)