ESRI Dev Summit 2008 – The real skinny
I am going to try to keep this post clear of chatter about how ESRI is doing things and my opinions on them. I would like to thank all the ESRI developers who took the time to answer some of my questions. So, here are some important tech notes to take away from the conference.
REST API
- The REST API does not support curves to be returned.
- When curves are encountered, they are densified automatically and returned as polylines.
- Support for curves is being planned for in the future versions.
- They were also open to the idea of GeoJSON converters in the JavaScript API for the future.
- The shapes returned by the REST API are not GeoJSON compliant. But the ESRI developers seem open to support GeoJSON when it is finally ratified by the standards committee.
- The REST API does all its work by using the ArcGIS Server SOAP API. See the notes below for the reasons why.
JavaScript API
- The ESRI developers chose to use the DOJO toolkit primarily because its graphics capabilities.
- The DOJO client-side libraries provide support for performing some simple spatial operations like ‘intersection’ on the client-side.
- The intellisense for the Javascript API currently has some problems in Visual Studio 2008.
- The client-side layers provides support for attributes on the client-side features. Attributes on client-side features are not even supported in VE and Google Maps.
- The client-side layers support events.
- Currently, only one client-side layer is supported. The reason for this being (according to the ESRI developers) there are problems with listening to events on features that are not on the top-most layer. ESRI is currently researching the problem and is trying to find ways to make multiple client-side layers work.
- The client-side JavaScript for the .NET ADF has been completely re-built in 9.3.
- Changes are already planned for the JavaScript API between the Beta version and the final release.
- An object model diagram for the JavaScript API might also be available.
Map cache
- ArcGIS Server 9.3 supports the following tiling scheme
- VirtualEarth (256X256)
- Google Maps (256X256)
- ArcGIS Online (512X512)
- Custom
- The Map cache generated using the VirtualEarth tiling scheme does not generate tiles using the quadkey naming scheme for the file names generated but only the tiling scheme is the scheme.
- The REST API has built-in support for handling quadkey naming scheme, it maps the quadkeys to the file names generated by the ArcGIS Server cache.
- The WMS Service of the MapServer object will start taking advantage of the Map cache if available starting in 9.3.
Geodatabase
- Sounds like SDE will support storing shapes in SQL Server 2008 as SQL CLR types also. This should enable other applications to access and use spatial data in the SDE without ArcObjects.
Note: It was decided to use SOAP over DCOM for the REST handlers to talk to ArcGIS Server because ESRI realized after running some metrics that SOAP was more performant than DCOM to access ArcGIS Server functionalities. The chatty nature of DCOM reduces its performance over SOAP. When using DCOM, the client uses a proxy to communicate with the server object. That means every time the client accesses a property on the server object, it is accessed over the network. But when using SOAP, an object representation is completely serialized and sent to the client so that property access doesn’t need to be over the network.
Even though it is not completely documented, it is possible to access Server Object Extensions over SOAP directly with some custom programming.
Subscribe
Follow Me
Contact me
Vishful thinking... 
Hopefully they will find a way to make the javascript API work with more than one layer. I can certainly see situations where you have multiple point layers plus a polygon layer that you want to work with the javascript API.
It’s a shame about not generating tiles using the VE Quadkey – it seems as though it would be a simple option to provide. Maybe it’s a way to tie you to actually having a copy of AGS on the server that will serve the tiles. If the tiles were generated with the quadkey, you could generate the tile images on one server, then copy them to a non-AGS server and point a VETileLayer to those images to incorporate them into a VE map.
Hi Tim,
I agree with you in both cases. For the second case, it should possible to write a tool that can generate the tiles in the quadkey naming scheme for all WMS services (not just ArcGIS Server) with moderate effort. Something similar to TileCache but in .NET generating tiles in the quadkey scheme.
Thank You,
Vish
http://www.Vishcio.us
Vish,
You could do that or you could create a generic handler in ASP.NET that translates from the quadkey pattern to whatever AGS’s naming scheme is (I’m not familiar with it). I’m sure you’ve run across the code on the internet for overlaying a WMS layer on VE – that code contains some functions for converting from a quadkey to a lat/long extent. I would imagine that it would then be possible to determine the AGS tile to use based on that lat/long extent. So, you could generate your tiles in AGS, copy them to your web server, include the generic handler that translates from quadkey to AGS tile name, and point your tilelayer to that handler. Of course, that’s a display only method – I guess you’d still need AGS if you want to incorporate things like an identify or select by polygon.
Hi Tim,
The handler to convert from the quadkey naming scheme to the AGS naming scheme should be pretty simple to do. Actually, from what i heard at the Dev summit it is included as a feature in 9.3. But I tend to beleive that if I can do away with the handlers then it is a good idea. Having the tile cache in the quadkey naming scheme does not require a handler and VE can access the images directly. But that being said, I would like to keep the tiles in the AGS naming scheme because that will allow for multiple clients to access the same cache and require a tile cache for the various clients like VE, Google Maps, OpenLayers etc.
Thank You,
Vish
http://www.Vishcio.us
Tim / Vish,
The VE quadkey is supported for cached map services in web mercator.
For e.x.: http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Portland/ESRI_LandBase_WebMercator/MapServer/vetile/02123022
Monitor the transactions on this page ( http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Portland/ESRI_LandBase_WebMercator/MapServer?f=ve ) in Firebug or Fiddler and you’ll see these quadkey urls. The 3D option also works because of the quadkey support.
Cheers,
Keyur
Hi Keyur,
Thank you for the links. But since the tiles are not in the quadkey naming scheme, I will not be able to server out the tiles without ArcGIS Server. If the tiles were generated in the quadkey naming scheme then the map can served out with just a web server over VE.
Thank You,
Vish
http://www.Vishcio.us
[…] https://viswaug.wordpress.com/2008/03/22/esri-dev-summit-2008-the-real-skinny/ […]
Can ArcGIS Server 9.1 provide WMS Service of the MapServer object?
@Vish:
>>But since the tiles are not in the quadkey naming scheme, I will not be able to server out the tiles without ArcGIS Server.
What makes you think that? By a simple conversion using javascript, you can serve AGS tiles in VE/GM without AGS server. The naming scheme is really not an issue.
Vish,
I was just researching SOE’s and came across this post – you mention:
‘Even though it is not completely documented, it is possible to access Server Object Extensions over SOAP directly with some custom programming.’
I haven’t been able to find any docs that describe how to expose your SOE directly – i assume this involves ensuring a wsdl exists which defines the contract for your SOE..? Have you ever used this method, or do you use SOE’s directly through ArcObjects calls?
Cheers
Simon