Dave Bouwman Releases the ArcGIS Server Virtual Earth Tile Server
Dave Bouwman has cleaned up his AGS Virtual Earth Tile Server and has posted the code.
- HttpHandler (.ashx)that responds to Tile requests from Virtual Earth
- Supports multiple layers/map services through the same handler
- ArcGIS Server Tile Provider uses the AGS SOAP API (fast!)
- Projects the data – can be used with any ArcGIS Server map service
- Extensible design allows for additional Tile Providers – i.e. ArcIMS, Image Server
- Extensible design allows for additional storage providers – i.e. Amazon S3, DBMS
- Easy to use – just edit the web.config file
Dave hopes to add providers for both WMS and ArcIMS services. Some of the history behind why this project was developed can be found in a blog post from a couple weeks ago.
This is why a RESTful API is so important to development of ArcGIS Server. Rather than being tied down to the WebADF, you can start using ArcGIS Server in ways that we haven’t before. Just because you are the ESRI Server Stack shouldn’t limit you to using only the ESRI ADFs. We’ll be seeing more about this in the next few weeks running up to the DevSummit from many folks as we start getting organized with ESRI ArcGIS Server community development. If you use .NET with ArcGIS Server, get involved with ArcDeveloper.net.
I’m somewhat disappointed that Dave has continued to develop this TileCache clone. I wish I knew what TileCache did wrong that Dave feels like this is better than just writing an ArcGIS SOAP provider for TileCache…
(And don’t tell me that it’s Impossible to set up on IIS, not when there’s a blog post with pictures of every step of the process…)
@Christopher
I don’t see why your TileCache & “Tilecache.NET” can’t exist side-by-side and cross polinate each other, making each other stronger & better.
@Christopher,
It’s not that TileCache does anything “wrong” – it’s awesome and does much more than my Virtual Earth tile server.
The issue I see is that pitching a python solution to government agencies is much more difficult than simply saying – “it’s .NET”. We deal with clients who run very tight systems. Asking them to do the python setup is not going to happen. Maybe you are having more luck in this are than we are, but in talking with many other people, this is a common scenario. Since these are the constraints we have to work with, I think that having a .NET version should be a good thing.
As for this drop, it was something I needed to build as proof of concept for a project, and I thought I’d share it.
Dave,
It seems that the ITileProvider.cs file is missing in source code…
@Christopher, Dave Bouwman
Christopher,
Dave has a very valid point. When you come at this from an ESRI stand point ie. (local and Federal Government) MS and .net are the rule. Even if you have something that works better (Tilecache) you can’t use it without a huge fight. And from a contractor’s perspective (Dave) your job isn’t to battle with the CTO over their architecture, it’s to get a job done.
IronPython.
I’m not sure what the problem is with Python is here. You can’t install ArcGIS without installing Python.
I should say that .NET devs really like pure .NET so there is some pushback from Python (though I’m not sure so much in this crowd).
@akhor,
I’ll check into that – had some issues doing a clean export from SVN for the drop to ArcScripts – you can get it from the assembla repository though…
http://svn2.assembla.com/svn/arcdeveloper
@Python issues
Yes python is installed with Desktop & Server, but these are not agencies which run their websites on the AGS box. The web servers are dedicated – we’ve even had push back about dropping the ADF run time on them.
Anyhow – the gist of it as CMH puts it – our job as consultant’s is to get the job done so that it works in the target environments. In our experience that has meant Java or .NET. Since we also do a fair bit of work customizing the ArcGIS desktop, it’s just easier to specialize in .NET
I’m not doing work where Dave is but I can attest to the same kind of issues with my customers as well. The web server has to stay “clean” or you can’t deploy it.
“Clean” is a moving target that depends upon the definition of the designated approving authority. It’s a lot of fun.
I believe Iron Python is one of the target languages in VS 2008, so maybe a python .NET deployment will become more acceptable in the future.
Let me kill the IronPython side-note. AFAIK, Tilecache still doesn’t work with IronPython.
http://mapwrecker.wordpress.com/2007/06/18/python-vs-ironpython-tilecache/
here the wrong think it seems to me that (public) government agencies are able to use commercial .NET and not OS Python. Luckily in Italy things are changing
Paolo, I have not had any problem with Python with my Federal Government clients here in the U.S.
Actually, Python isn’t a problem for me either but I did just rotate out of a site that had a couple of extra justification steps to get open-source software approved. The policy included a blanket statement declaring that OSS was inherently riskier (wrt security) than commercial software. Therefore, there was extra work involved to get it approved. It was actually easier to get a commercial product by a foreign vendor approved.