ESRI announced that they are releasing the ArcGIS REST API as open technology. I've got an ISP running Sql Server 2008 with IIS7.
Does anyone know of a good walk through showing how I can write C# using WCF to expose spatial tables compliant with a particular spec (ideally ESRI's)?
Does anyone know where ESRI's spec is?
Esri has released their GeoServices REST Specification 1.0:
The GeoServices REST Specification provides a standard way for web clients to communicate with geographic information system (GIS) servers through Representational State Transfer (REST) technology. Clients issue requests to the server through structured URLs. The server responds with map images, text-based geographic information, or other resources that satisfy the request. Although the GeoServices REST Specification was originally built to communicate with Esri's ArcGIS® Server product, the specification has been opened such that developers can expose the GeoServices REST Specification request structure from other back-end GIS servers or processes.
I believe that this is what you may be looking for.
I just used the link Jason posted above. I can't imagine when its released, the official spec will be much different. It was mostly a roll-up-your-sleeves, fire up Fiddler, hit the 10.0 sample servers and start hacking away at the implementation. There's nothing that's impossible, just tedious with lots of little issues to take into account. We won't even make ours 100% compatible but it covers 85% and all the client apis seems to work pretty well (that was the only reason I did it to begin with)
here's a demo catalog (lots of little bugs in there :) [bFlood - removed old link]
we're running it on AppEngine (python) and its pretty tightly coupled with the underlying spatial structures but it probably could be made into a decent .Net WCF project. Not sure how we would distribute it though
You can have your FeatureService running in minutes if you try out the Arc2Earth Sync beta. the backend works with Google Fusion Tables and CartoDB but we'll be supporting other providers very soon. You don't need anything except ArcView 9.2 or greater...
here's a blog post showing how to start collecting field data in minutes using the ArcGIS.com mobile apps: http://www.arc2earth.com/2012/03/arc2earth-sync-live-mobile-data-collection-in-5-minutes/
The only documentation that I know of for esri's REST API is in their online help here:
http://help.arcgis.com/EN/arcgisserver/10.0/apis/rest/index.html
This is written more from the perspective of a consumer than a provider, but should be hackable.
There are parts of this API that are quite proprietary (some of the output formats) and impossible implement by an open source project unless these format specifications are also made available.
As well, some of the REST APIs aren't especially RESTful. For instance, look at the Feature Service. There seem to be separate "endpoints" for add/update/delete/query instead of using standard HTTP verbs to operate on resources. This puzzles me; I know that esri has some pretty smart people there who understand REST. My guess is that these calls map to some kind of SOAP interface, and esri felt that it would be easier for them and their clients if they maintained consistency between them.
My opinion? If you are only looking at sharing data (not map configuration, metadata, etc) and are not in a rush, you may be better off waiting until Microsoft figures out how they're going to represent spatial data types in EDM. With this in place, you could easily create truly RESTful access to your spatial tables using OData and probably RIA-enabled OData at that. This may be pie-in-the sky for all I know though.
Are you looking at exposing spatial tables from SQL Server 2008 Spatial? ESRI MapIt does this already and I believe the licensing allows those with AGS to have access to ESRI MapIt.
Some screens of what this looks like can be found on my blog: http://geo.geek.nz/development/hiding-databases-from-unauthorised-users-when-using-esri-mapit/
No need to write something yourself? ;)
Cheers
I have done this already in an application. I did not fully implement the full REST api, but enough to get a query task to run and format the JSON correctly. I used ASP .NET MVC to build my endpoint. I tried doing this about a year ago with WCF and the JSON output was not formatted in such a way to work. The trick with MVC is to make sure you have a JSONP result which will pull the callback query parameter and make the correct jsonp response. I will try to post something up. You can take a look at the response here:
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.io.script.jsonp_dojoIoScript2._jsonpCallback
However, only the callback parameter is used:
http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents?callback=woot
Edit: Here is how to implement a JSONP result in ASP .NET MVC
https://stackoverflow.com/questions/758879/asp-net-mvc-returning-jsonp
Edit #2: Here is a code example that I quickly made and put up on dropbox.
http://dl.dropbox.com/u/28924446/EsriGeoServicesExampleMvc3.zip
It sounds like you may just end up replacing the functionality of ArcGIS doing that. I would recommend utilizing an existing open source project to implement such a system if one becomes available that supports that API, perhaps write you own adapter for an open source project. Maybe one exists but I have not looked very hard yet. I'm not sure they have released a full API specification just yet but if you are in a hurry you could just use the existing API documentation and test your implementation against existing ESRI software.
here there is an example: http://www.arcgis.com/home/item.html?id=6d28a606369c43fd9a6f929541ae7c93
@JasonBirch - i think the main draw for even doing this is the ability to integrate with esri apps/apis/arcgis.com. If esri pulls the plug on using these cheaply (free), it becomes far less important. It's unclear to me what they plan to do with ArcGIS.com and even how it is licensed right now. I saw it as a central location for data/services where web applications could be registered, something like an appstore for esri data. 3rd parties register multi-tenant web(cloud) apps, esri takes a cut and your app is instantly available to all takers compatible with the rest api spec. in this light, it makes sense to open the rest api and allow as many services to integrate with the hub as possible. geospatial data search/storage is quickly on its way to to being commoditized, so move it up a notch and try to control the app space.
I think your OData comment has merit but IMO, that's a ways off. and more importantly, without a extensively distributed and well loved client app (something Google Earth), any well-written spec has the potential of withering on the vine. Not saying that's the case with OData, there are lots of MS devs out there who will get this wired up for free in VS, but I don't see it in the short term. my 2 cents...
(btw, there seems to be a pretty short comment length, hence the new answer instead)
