Over the years I've seen a few "developer" surveys put out by various GIS organizations, and they have all been pretty bland. After talking to a few people at the Developer Summit about this, I thought I'd see if we could do a little better - thus the launch of the 2008 Geospatial Developer Survey.

Why are you doing this?

The main reason is that I'm interested in knowing more about how other people doing GIS/Geospatial development work. How many people view themselves as software engineers vs. occasional coders who hack some stuff together as needed. I want to know if people are exploring and adopting the tools, patterns and practices that are common place in main stream software development. And if not, why.

And beyond my curiosity, I'm also looking for some insight as to what topics people want to know more about. Although I have some ideas, lets hear from you. I get a fair number of requests to write more "fundamentals" type posts, and at the same time get requests for more on patterns, Inversion of Control and Unit testing. Since I don't write this blog for a living, I need to focus my efforts, so I hope that this survey will help quantify which way I should lean in future postings.

Who should take the survey?

Anyone who writes any code that is geospatial in nature. From the Google Maps Mashup dudes, to those running some geoprocessing tasks with python. If you write code that has anything to do with a map, you're the perfect person to take the survey. Be sure to pass this url around to everyone you work with who is a geospatial developer - the more data points we get, the better. Who knows - we may even be able to influence the content at some conferences...

How?

It's simple - just follow this link to SurveyMonkey, and fill out the questions. Yes there are 30 questions, but they should be pretty quick - I'd guess no more than 10 minutes.

What Next?

I'll be leaving they survey open until May 9th 2008. Then I'll crunch the numbers and do a post or two about the results.

Link (for copy pasting to all your developer buddies):

http://www.surveymonkey.com/s.aspx?sm=cugzupf5rAG_2bIu5WJ_2f7rxQ_3d_3d

UPDATE 4/8 @ Noon: After recieveing some feedback on the questions, I have added more "Not Applicable" and "Other" options.

Starting from the little bit of hacked up code that I cooked up a while back, I've created an extensible, interface based, adaptive caching Virtual Earth Tile Server that can be extended to use any map rendering engine. The initial release has one Tile Provider which uses the ArcGIS Server SOAP API. In the coming weeks I will be adding providers for both WMS and ArcIMS services.

Project Features:

• 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.
• Includes a demo web page to get you up and running quickly.
• API Documentation compiled using DocProject is at http://doc.arcdeveloper.net/tileserver (coming soon!)
• Leverages the Castle Windsor Inversion of Control Container.
• Exceptions are written into a tile image so it's easy to debug your configuration.

Design

The Virtual Earth Tile Handler uses a Virtual Earth Tile Service Manager to actually do all the work. The Tile Service Manager contains a collection of Tile Services, keyed by a name. This allows a single instance of the Tile Handler to host multiple tile services. The handler determines which Tile Service to use by extracting the service name from the url of the request. Assuming your tile handler lives in a subdirectory called "tileHandler", a request to http://myserver/tileHandler/tahoe/<vetileindex>.ashx will look for the tahoe tile service, and use it's settings to create the map.

Tile Service is simply a named container for a Tile Provider (a class which creates map image tiles) and a Storage Provider (a class which can cache the images on disk)

The logic in the system is quite simple as shown below:

 

How to Configure Tile Server:

There are 2 main things you need to do to configure this for your site - add the layer to your Virtual Earth map control, setup a TileService in the web.config.

Adding a Tile Layer to the Virtual Earth Map Control:

Using version 6 of the Map control this is very easy (the Default.aspx file in the attached zip file has this code in it)

First Create a bounding box that will limit the area that Virtual Earth will make tile requests. This box is for Colorado.

var bounds = [new VELatLongRectangle(new VELatLong(40,-109),new VELatLong(37,-102))];

Next, create a Tile Source Specification. You will need to specify the full Url to the handler if your Virtual Earth page is not located in the same web application. What's important to note is that the name of the TileService must be in the url - in this case it's "colorado". You will need to change this to the name of the TileService you want this layer to pull from.
var tileSourceSpec = new VETileSourceSpecification("agssoap", "./colorado/%4.ashx");

From here, it's just setting some simple tile source properties...
tileSourceSpec.NumServers = 1;
tileSourceSpec.Bounds = bounds;
tileSourceSpec.MinZoomLevel = 10;
tileSourceSpec.MaxZoomLevel = 18;
tileSourceSpec.Opacity = 0.5;
tileSourceSpec.ZIndex = 100;

Finally you want to add the layer to your map
map.AddTileLayer(tileSourceSpec, true);

 

Setting up a Tile Service in Web.config

A Tile Service is a container for a Tile Provider and a Storage Provider, so we are going to set up these three things, and link them together. The web.config file in the download already has these sections in it - you will just need to change a few things.

Step 1: Configure the Tile Service

Change the service name to match what you put into the VETileSourceSpecification path, as this is the linkage between the Tile Service and the Url that the request is coming from. For now, leave the other elements alone.

The other sections specify the TileProvider and StorageProvider that this Tile Service will use. If you want to use different or differently configurated providers, just copy/paste the sections and rename them. The configuration syntax here is based on the Castle Windsor project, and you can get more information about how this works by reading Simone Busoli's articles here: Part 1, Part 2, Part 3, and Part 4.

Step 2: Specify the Map Service URL

Locate the following section in the web.config

 

Step 3: Change the StorageProvider location

The Storage Provider is used to cache the tiles as they are created. Thus the location you specify must have write privileges granted to the identity that the ASP.NET application runs as (ASPNET on Windows XP and NETWORK SERVICE on Windows Server 2003)

That's it.

Known Issues:

Occasionally empty tiles are returned from ArcGIS Server. I am still looking into why this occurs, but since the SOAP API actually returns an image, there is no way for the code to know that it's a blank image, and thus it is still added to the cache.

Do not use labeling in the map service. This is because the images are requested at their native tile size of 256 x 256. Thus the labels will be cramped into the tile, and you will have a lot of repeated labels across your map. In the future we may build out a tool that will pre-cook a tile cache, and when doing that you can request larger images which will not have this issue. For now, just turn your labels off.

Feedback / Bugs / Issues

Please use the ArcDeveloper.net forums to ask questions or raise issues. This way everyone will benefit, and it's less one on one emailing.

Source Code:

All the source code for this project is available at the ArcDeveloper project hosted at Assembla.com. You can get the source code from http://svn2.assembla.com/svn/arcdeveloper/tileserver/trunk

If you would like to contribute to the project, use the contact link at the top of this page and I will send you an invitation to join the project team.

Download

Download ArcDeveloper.net Tile Server v0.1 (from ArcScripts). This zip file contains the source code current as of February 3,2008.

Vote!

I also entered this code in the ESRI Code Challenge . If you are an EDN subscriber or are going to the 2008 Developer Summit, and find this code useful, I'd appreciate your vote!

 I have to admit that when I first saw twitter, I had a few thoughts, more or less in this order:

1. This is stupid and a waste of time
2. This is IRC "2.0" with mobile support
3. The txtmsg kids are gonna love this
4. I wish I had thought of it

Given that I had not thought of it, I've never been into IRC, and I'm not a txtr, I pretty much ignored it. Until this week... 

Background

Over the last week, I read Ship It! A Practical Guide to Successful Software Projects. I highly recommend this book to anyone who is involved with software development, as it is a quick read and hits on a number of great Agile ideas without espousing any formal methodology (i.e. Scrum). One practice that was new to me is sending out "Code Change Notifications" - simple summaries of what changes have been checked into the source control.

My initial gut feel was that it would be a waste of time, but their anecdote made me re-consider. In this anecdote, a couple developers on a distributed team have spent a day or so working on improving the performance of some section of code. When they have tweaked the code as much as they can, they check in their code, and send out a notification to the entire team. Another developer on the team, in another location, reads the notification. It turns out that this person has a background in high-performance algorithms, and is able to quickly review the code change, and re-work it for a 10 fold increase in performance.

Setting aside the fact that there is some misapplication of resources on this team, if the notification had not been sent out, the opportunity for this substantial improvement would not have occurred. Sending out the notifications basically pings the collective experience of the team. Most times little will come of it, and as long as the opportunity cost for sending out the notification is low (i.e. automated as part of the code check-in process), and it's quick to read, this still nets out positive if there is some occasional input.

Twitter in the Mix

Taken in this light, I now see twitter as a platform for real-time pinging the collective experience of a community. If someone fires out a "tech tweet" about what they are working on, maybe one person who just worked on something similar sees it and fires back an idea that changes your entire outlook on the problem. At the very least it's worth a try.

Since someone has to start this off, so as of Monday, I started simply sending out quick tweets relating to what I'm working on at any given time. This will be only technical stuff - no off-topic minutiae. If you want to follow along, you can view the feed here http://twitter.com/dbouwman, or sign up with Twitter, and have tweets sent to your IM or Phone.

Obviously there are scalability issues here - I don't want to get 1000 tweets a day, nor would anyone else, but that problem is quite a ways into the future. For now, let's see if this is useful

I spent some time this weekend re-tooling the ArcDeveloper.net web site. Here's a quick look...

I'm building it on top of the open-source, ASP.NET based, ScrewTurn wiki engine, with a few custom pages and a forum package thrown in. I'm still tweaking some of the CSS, some graphics and a few pages, but I hope to have it up for some beta testers later this week. If you are interested in kicking the tires, use the Contact link at the top of this page to let me know.

I'm also looking for people who may want to post some articles on the site (kinda like a stripped down, GIS-centric CodeProject). These will be kept in a separate secure sub-wiki, so you don't need to be concerned about someone else messing with your stuff.