ESRI ha annunciato che stanno rilasciando l'API REST di ArcGIS come tecnologia aperta . Ho un ISP che esegue SQL Server 2008 con IIS7.
Qualcuno sa di una buona passeggiata che mostra come posso scrivere C # usando WCF per esporre tabelle spaziali conformi a una specifica specifica (idealmente ESRI)?
Qualcuno sa dove sono le specifiche di ESRI?
Risposte:
Sembra che ESRI abbia appena rilasciato la specifica REST di GeoServices . Credo che questo sia ciò che potresti cercare.
Ho appena usato il link che Jason ha pubblicato sopra. Non riesco a immaginare quando verrà rilasciato, le specifiche ufficiali saranno molto diverse. Per lo più è stato un rimboccarsi le maniche, accendere Fiddler, colpire i server di esempio 10.0 e iniziare l'hacking all'implementazione. Non c'è nulla di impossibile, solo noioso con un sacco di piccoli problemi da tenere in considerazione. Non renderemo la nostra compatibilità al 100%, ma copre l'85% e tutte le API client sembrano funzionare abbastanza bene (questa era l'unica ragione per cui l'ho fatto per cominciare)
ecco un catalogo demo (molti piccoli bug lì dentro :) [bFlood - rimosso vecchio link]
lo stiamo eseguendo su AppEngine (python) ed è piuttosto accoppiato con le strutture spaziali sottostanti, ma probabilmente potrebbe essere trasformato in un discreto progetto .Net WCF. Non sono sicuro di come lo distribuiremmo però
salute brian
Aggiornamento - 08/03/12 - Ho appena visto questo post apparire nello stackexchange, quindi ho pensato di aggiornare il contenuto. Puoi far funzionare FeatureService in pochi minuti se provi Arc2Earth Sync beta. il backend funziona con Google Fusion Tables e CartoDB ma supporteremo presto altri provider. Non hai bisogno di nulla tranne ArcView 9.2 o versioni successive ...
ecco un post sul blog che mostra come iniziare a raccogliere dati sul campo in pochi minuti utilizzando le app mobili ArcGIS.com: http://www.arc2earth.com/2012/03/arc2earth-sync-live-mobile-data-collection-in-5 -minuti/
L'unica documentazione che conosco per l'API REST di esri è nella loro guida online qui:
http://help.arcgis.com/EN/arcgisserver/10.0/apis/rest/index.html
Questo è scritto più dalla prospettiva di un consumatore che di un fornitore, ma dovrebbe essere hackerabile.
Ci sono parti di questa API che sono piuttosto proprietarie (alcuni dei formati di output ) e impossibili da implementare da un progetto open source a meno che queste specifiche di formato non siano anche rese disponibili.
Inoltre, alcune delle API REST non sono particolarmente RESTful. Ad esempio, guarda il Servizio funzionalità. Sembrano esserci "endpoint" separati per aggiungere / aggiornare / cancellare / interrogare invece di usare i verbi HTTP standard per operare sulle risorse. Questo mi confonde; So che esri ha alcune persone piuttosto intelligenti che comprendono REST. La mia ipotesi è che queste chiamate si associno a una sorta di interfaccia SOAP, ed esri ha ritenuto che sarebbe stato più facile per loro e per i loro clienti se avessero mantenuto la coerenza tra loro.
La mia opinione? Se stai solo guardando la condivisione dei dati (non la configurazione della mappa, i metadati, ecc.) E non hai fretta, potresti stare meglio in attesa che Microsoft capisca come rappresenteranno i tipi di dati spaziali in EDM. Con questo in atto, potresti facilmente creare un accesso veramente RESTful alle tue tabelle spaziali usando OData e probabilmente ODIA abilitato per RIA. Questo potrebbe essere un gioco da ragazzi per quanto ne so.
Stai cercando di esporre le tabelle spaziali da SQL Server 2008 Spatial? ESRI MapIt lo fa già e credo che le licenze consentano a chi ha AGS di avere accesso a ESRI MapIt.
Alcune schermate di come appare possono essere trovate sul mio blog: http://geo.geek.nz/development/hiding-database-from-unauthorised-users-when-using-esri-mapit/
Non hai bisogno di scrivere qualcosa da solo? ;)
Saluti
L'ho già fatto in un'applicazione. Non ho implementato completamente l'API REST completo, ma abbastanza per ottenere un'attività di query per eseguire e formattare correttamente JSON. Ho usato ASP .NET MVC per costruire il mio endpoint. Ho provato a farlo circa un anno fa con WCF e l'output JSON non è stato formattato in modo da funzionare. Il trucco con MVC è assicurarsi di avere un risultato JSONP che tiri il parametro della query di callback e realizzi la risposta jsonp corretta. Proverò a pubblicare qualcosa. Puoi dare un'occhiata alla risposta qui:
http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents/query?f=json&where=1%3D1&returnGeometry=true&spatialRel=esriSpatialRelIntersects&outFields= * & outSR = 4326.pc
Tuttavia, viene utilizzato solo il parametro callback:
http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents?callback=woot
Modifica: ecco come implementare un risultato JSONP in ASP .NET MVC
/programming/758879/asp-net-mvc-returning-jsonp
Modifica n. 2: ecco un esempio di codice che ho creato e messo rapidamente su dropbox.
http://dl.dropbox.com/u/28924446/EsriGeoServicesExampleMvc3.zip
Sembra che potresti finire per sostituire la funzionalità di ArcGIS. Consiglierei di utilizzare un progetto open source esistente per implementare un tale sistema se uno diventa disponibile che supporta quell'API, magari scrivere il proprio adattatore per un progetto open source. Forse ne esiste uno ma non mi sono ancora guardato molto. Non sono ancora sicuro che abbiano rilasciato una specifica API completa, ma se hai fretta potresti semplicemente usare la documentazione API esistente e testare l'implementazione con il software ESRI esistente.
qui c'è un esempio: http://www.arcgis.com/home/item.html?id=6d28a606369c43fd9a6f929541ae7c93
@JasonBirch - penso che l'attrazione principale anche per fare questo sia la possibilità di integrarsi con le app esri / apis / arcgis.com. Se esri stacca la spina usando questi a buon mercato (gratis), diventa molto meno importante. Non mi è chiaro cosa intendono fare con ArcGIS.com e anche come sia concesso in licenza in questo momento. L'ho visto come una posizione centrale per dati / servizi in cui le applicazioni web potevano essere registrate, qualcosa come un appstore per i dati esri. Le terze parti registrano app Web (cloud) multi-tenant, esri fa un taglio e la tua app è immediatamente disponibile per tutti gli acquirenti compatibili con le altre specifiche API. in questa luce, ha senso aprire il resto api e consentire a quanti più servizi di integrarsi con l'hub possibile. la ricerca / l'archiviazione dei dati geospaziali sta rapidamente raggiungendo il livello di mercificazione, quindi spostalo su una tacca e prova a controllare lo spazio dell'app.
Penso che il tuo commento OData abbia un merito, ma IMO, questo è un modo. e, soprattutto, senza un'app client ampiamente distribuita e amata (qualcosa di Google Earth), qualsiasi specifica ben scritta ha il potenziale di appassire sulla pianta. Non dicendo che è il caso di OData, ci sono molti sviluppatori di MS là fuori che lo faranno cablare gratuitamente in VS, ma non lo vedo a breve termine. i miei 2 centesimi ...
(a proposito, sembra che ci sia una lunghezza del commento piuttosto breve, quindi la nuova risposta invece)