For all you .NET wonks out there, I had some serious trouble finding the solution that fit my business (CitySourced – http://www.citysourced.com) when it came to processing geo spatial elements. Yes, there’s the SQL Server 2008 and their new spatial types (which I use as well), but there was nothing that allowed me to work with geo spatial elements directly in my .NET application. We’re now using ESRI’s ArcGIS 10technology for a lot of the heavy lifting at CitySourced, but there is definitely a need for doing some of this in-application.

That being said, I’ve collected the libraries that were most useful to me and zipped them up. I’m doing this because the library I’m most fond of was the most difficult to find and get working – SharpMap 2.0 beta.

Download my .NET_GIS_Libraries

In addition to the download, I’ve decided to add links to all my favorite websites. Enjoy!

http://sharpmap.codeplex.com/
http://dotspatial.codeplex.com/
http://projnet.codeplex.com/
http://geoapi.codeplex.com/
http://mssqlspatial.codeplex.com/

And a great how to blog for SharpMap 2.0 – a must read!

http://geekswithblogs.net/JuanDoNeblo/archive/2008/04/13/showing-esri-shapefile-layers-on-a-virtual-earth-map.aspx

Now that CitySourced is on Microsoft’s Azure cloud services, I’m a huge fan of what it offers both developers and startup companies. That being said, I wanted to put a quick note out there about a fix to a bug I found to help spread the knowledge I’ve gained getting into the nuts and bolts of it. With CitySourced, the original application was written in .NET (C#, 3.5 Framework), so the port was relatively simple. Once we started playing around with it though, the development app fabric kept crashing on us for no apparent reason. I searched Google (and Bing) and came up with nothing. Upon closer inspection of the code, it appears that if you redirect and specify the “EndResponse” flag as true, the app fabric bombs. So, in summary:

This BOMBS -> Response.Redirect(“~/my-new-url”, true);

This WORKS -> Response.Redirect(“~/my-new-url”, false);

I guess Azure doesn’t like ending the response prematurely. Luckily, we had abstracted any and all redirects to a utility class (eg, ContextUtil). So we updated our code in one place and viola! Our code worked perfectly.

I’ll be doing a pretty in depth post on our complete migration, what I like, what I didn’t like, etc. Stay tuned!