I was running into a LOT of weirdness with my Windows Xp installation, so I figured I'd upgrade to Vista 64 instead of futzing with another re-do of Xp.

I've been running Vista on my notebook an home workstation for about 6 months with no issues, and with my MSDN subscription, so it's a no-cost thing - just grab the disk and an authorization code, and let 'er rip.

Hardware Compatibility is one of the first things you should be concerned about when jumping to the 64-bit platform, but we had pre-planned this to some extent. When we built out our development boxes, we followed the "CodingHorror Ultimate Developer Rig" parts list. So other than the quad core CPU, I've got exactly the same box. Since Scott Hanselman has been running Vista 64 for a long time, with few issues (here's a link to his podcast on the Vista 64 Developer Experience) this should go pretty smoothly.

One nice thing about re-paving a machine is you get to clean out all the crud that accumulates over time. So, as I re-built things, I created a list of all the stuff I could not live without.

Vista Components:

• IIS w/ IIS 6 compatibility
• Disable User Access Control - secure, but a hassle

Development Tools:

• Visual Studio 2008
• Aptana Studio - Javascript / Ajax IDE
• MyGeneration - free code generation tool
• MbUnit - unit testing on crack
• TestDriven.net - Unit Testing harness for Visual Studio
• GhostDoc - why write your own Xml comments?

Productivity:

• Office Enterprise 2007
• Visio 2007
• Slickrun  - launcher goodness
• FolderShare - sync folders across multiple systems
• Notepad++ - notepad with tabs and syntax hilighting
• FireFox
  • FireBug - must have for Ajax development
  • FoxMarks - sync bookmarks across multiple systems
  • IETab - runs IE inside FireFox - good for SharePoint

GIS:

• ArcGIS Desktop (Editor) 9.3 Beta
• uDig

So, .NET developers - what other tools do you install on a fresh box?

We recently moved from using Exchange to Google Apps. The transition has gone really smoothly, but there have been a few hurdles - mainly surrounding synchronization of Mail and Calendar across multiple devices.

While the Google Apps are all web-based, accessing them in a browser is not always an option - particularly when on airplanes. Additionally - if you rely heavily on your calendar for reminders like I do, remembering to keep a browser open on your calendar page is just one step too many. ;-)

So - here's my device situation:

Under Exchange, my notebook and workstation would connect to Exchange for email and calendar, and synchronization was automatic. My phone would pick up email via IMAP to Exchange, but the calendar was synched when I connected the phone to either PC via a USB cable. Overall pretty good, but the calendar synch to the phone was a little more involved than I'd like - why not synch over the air?

Anyhow, with the move to Google, I can of course access mail and calendar from all three via a web browser. This is fine for email on the PC's, but a little less than optimal for the calendar. Needing to have a calendar open to get reminders is not good for me. Call me old school, but I like Outlook - as far as email and calendar go - it works for me. 

Connecting Outlook with Google Apps

Actually getting a single instance of  Outlook talking to GMail via POP or IMAP is pretty easy, and well documented. If you use IMAP, then you can have multiple clients systems connected and everything is synchronized for you.

The calendar is another matter. For PC's you need to run the Google Calendar Synch, which will copy items between your local Outlook calendar and a Google Calendar. It does the sync on a scheduled basis, so there may be some lag, but since you are planning things in the future, a 10-30 minute lag should not be a big deal.

On my phone, I'm using Mobile Outlook connecting to IMAP for mail, along with GooSync keeps my mobile Calendar in line with my Google Calendar. What's sweet it that this works bi-directionally - over the air - something which was not an option with our Exchange setup.

If you are thinking about jumping to Google Apps, I'd say go for it. The transition has been smooth and everything we need is working with a lot less headaches for our IT staff.

Based on the outcome of the Developer Survey, I thought I' put together some posts on the common patterns referenced in some of the questions, starting with the Model View Controller (MVC) family.

There has been plenty written about MVC on the formal side of things - here are two good sources of information - Wikipedia MVC entry,  and some thoughts from Martin Fowler.

The Basics

The MVC family of patterns are about separating the presentation of data from the business logic surrounding the management of the data. There are many other patterns based on the key MVC ideas - Passive View, Supervising Controller, Presentation Model and Separated Presentation are 4 such patterns. The differences are subtle, and all share they key idea of separating the presentation logic from the business logic, from the data itself. It's worth noting that the opposite of MVC family is called "Autonomous View" in which all the logic is in the form itself - so if this is how you are developing, now you can use a fancy name for it!

Since MVC was one of the first patterns that dealt with this separation, we'll start with it, and look at the three components...

Model:

The model is the data and it's usually a class. So in GIS-land, it could be a "Parcel" class, which may have a Geometry property. The important part is that this class has no dependencies on the presentation layer, or the controller. It's just a dumb data container. Typically this class will implement one or more interfaces, which the View and Controller will utilize. Interfaces are used a lot in these patterns, so here's a link to an article that compares Abstract Classes and Interfaces that can serve as a refresher if needed.

View:

As the name suggests the View is responsible for organizing and presenting the Model. Usually this means showing it visually on a form. In order to remove dependencies between the View and the Model, the View will interact with an interface, instead of a specific view class - i.e. IParcelFeature instead of "Parcel". The view typically raises events when the user makes changes in the interface, and exposes properties allowing the Controller to "see" the model or other state of the view. The View does not make any changes to the Model itself (in some  MV* patterns does not actually have visibility of the model - the controller sets all the control values directly, and responds to all control events). Again, the events and properties of the View are defined via an interface.

Controller:

The name conveys things pretty well - this is the business logic component that controls what actually happens to the model when an event occurs in the view. There may be multiple controllers that can work with a given class, or multiple model classes that can work with a given controller. This is where the Interfaces on the Models come in. If the Controller's "contract" is based on an Interface (IParcelFeature), then we can use the Controller with any class that implements the interface. Similarly, the Controller also implements an Interface, which is it's contract with the View.

Pulling it to all together:

In MVC, the Controller gets a model and a View. It then passed the required data to the View which renders the UI. When the user interacts with the UI (i.e. clicks a button), the View raises events, which the Controller responds to by making required changes to the Model, which is then used to update the View.

Why Bother?

So - this is nice, but why separate things out like this? There are a number of reasons. First is known as Single Responsibility. This concept basically says that a class should have one purpose, and anything not connected with that purpose should be in a separate class. In regards to the subject at hand, it would tell you to avoid mixing presentation code, with business logic because they are not actually related.

Another reason for MVC is re-use. If you model your application like this, you can plug and play the components - particularly the View. So, suppose you need to create a business application that has a windows forms client for some functionality, a web client for some other functions, and a web service API. You can build out a model, a controller, and three views - one for the windows forms application, one for a web form, and a third (more limited one) for the web service.

A final (and biggest) reason is testability. If you keep the Model (data) separate from the View (User Interface) which is separate from the Controller (business logic), writing unit tests becomes much easier. If you've implemented interfaces as the contract between the components, you can test the components individually.

The Pain of Testing

Without getting too deep into unit testing, the basic idea is to have a test harness which spins up various classes in your code, and executes methods. This gets complicated because our classes have dependencies on data - stored in databases, shape files, whatever. If we want to re-run our tests frequently, we want to be sure our test data is static - otherwise the tests break, and that defeats the purpose. So - the next best option is to create "fake" static data in our tests. The brute force method would be to create specific test classes which implement the required interfaces (ISomeView, ISomeModel etc), but just contain enough logic to complete the test. Depending on the test you would have an invalid geometry, invalid PIN number or a myriad of other conditions. This would allow you to create test "Parcels" in your unit test harness, that you could then pass to the Controller to test it's methods, without actually connecting to a shape file. You could also create a class that implemented the View interface, and use that to raise events and ensure that the Controller reacted correctly. Essentially you can write unit tests for everything but the "click" event handler in the UI layer. Since that code was likely written for you by the IDE, and it's super basic, it's not a really high priority for testing.

Easing the Pain of Testing: Dynamic Mocking

Of course that's a lot of work, and developers hate extra work, so tools were created to help out. While this is beyond the scope of this post, I'm talking about "mocking" frameworks, such as NMock, RhinoMocks or TypeMock. These frameworks can create a "test dummy" class that implements a specific  interface right in the test definition. You basically "record" some values into the Mock, then pass it into a method, and it can validate behavior.

Of course you still need to fill up the dynamically mocked Interface with valid data - and the geometries are likely the scariest thing to start with. So that's where I started a few years ago.

I can haz code?

I don't have anything lying around that's easily sharable, but I did post a sample about Supervising Controller code about a year ago. The code is in VB.NET, with a Visual Studio 2005 solution, and is oriented towards showing how to create a plug-in framework, while leveraging Supervising Controller, so that's the gist of the article. It also does not have any tests, but I'll be posting more leveraging MVC patterns and unit testing in the future.

Plug-in Framework & Supervising Controller Example (Article - read this before digging into the code)

Download Sample Code

Summary

The idea here was to introduce the main idea of the MVC pattern - separation of behavior logic from presentation logic, usually to facilitate testing. The actual implementation of this idea can take many flavors, and can vary in complexity, but the underlying concept is the same.

We just put up another "demo" site - this time working with Sanborn to provide visualization for their wildfire risk model outputs they have created for the Texas Forest Service. For information on the data, there is contact information on the "About" tab.

From a technical stand-point, we added a few new features to this viewer...

Dealing with Multiple Tile Layers

The viewer is pulling in multiple tile services, representing multiple layers in a map, as opposed to a single "fused" tile layer. This is the first time I've implemented multiple layers using the ArcGIS Server Tile Cache code, and it turns out it's currently a bit of a pain. For this site, we've got 7 tile layers, and to do that with the current tile server code, I needed to create 7 map services (mxd's), and then configure 7 tile services in the TileServer. Clearly this should be streamlined. For example, the url http://65.101.234.201/tileservice/txfirewfsi/023131001.ashx pulls a specific tile from the txfirewfsi tile service. (shown below)

However, I'm thinking that it would be nice to be able to add a layer name in the url -'parcels' in this case -   http://65.101.234.201/tileservice/txbasemap/parcels/023133.ashx. This way you could specify the fused tiles, or just a specific layer.

Adjusting Layer Transparency

This was easy, if not obvious. Adding in a Dojo.slider, and hooking up some events was pretty simple. However, it turns out that changing the .Opacity property of a VETileSourceSpecification has no effect after the layer has been added to map. Instead you need to delete the layer and re-add it with the new opacity. Since the browser is caching the tiles, this is actually very fast.

Virtual Earth 3D

This was also the first time I tried throwing things into 3D mode. It took a few quick tweaks in the javascript, and some different CSS for the markers, but for the most part - it "just worked".

There are a few issues with the dojo menus that I'm going to sort out so I'll save the Url for the 3d page until that's dialed.

So, this took about 3 days to pull together -- if you are looking under the covers, the code is VERY "demo" and has some issues - there are a few weird things with the layer list checkboxes and I have not really tested in IE7, and all bets are off with IE6. I'd love to hear thoughts & ideas though.

So I've been using the Dojo toolkit for a while now, but mainly for the Dijit and DojoX UI components.  For the actual Ajax communication layer,  I've been relying on the Microsoft Ajax framework because of it's seamless integration with the ASP.NET Web Service model. Since I've got the whole mess of Dojo already being loaded into the browser, I figured I should drop the crutches, and work out how to work directly with the Dojo ajax framework.

The one downside of this is that you no longer get the client side proxies for your ASP.NET Web Services. Thus today's article - how to directly access an ASP.NET JSON Web Service using dojo.xhrGet.

Part 1: Create a Web Service

This is pretty simple - just add a web service to your web site. I tend to put the code right in the asmx file, rather than in the code-behind in app_code, but that's just personal preference.

          <%
          @ 
          WebService 
          Language
          ="C#" 
          Class
          ="ASPWebService" 
          %> 
          using System; using System.Web; using System.Web.Services; using System.Web.Services.Protocols;
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] public
class ASPWebService : System.Web.Services.WebService {
[WebMethod] public string SayHello()
{ return "Hello
to Dojo " + DateTime.Now.ToLongDateString();
} }

By default your web service will be configured to "speak" SOAP, which is fine if you are consuming it from another application, but for Ajax based browser apps, it's much easier to work with JSON.

Part 2: JSON-ify the Web Service

This is actually really simple - just include System.Web.Script.Services, and the [ScriptService] attribute to the web service as shown below.

          <%
          @ 
          WebService 
          Language
          ="C#" 
          Class
          ="ASPWebService" 
          %> 
          using System; using System.Web; using System.Web.Services; using System.Web.Services.Protocols; using System.Web.Script.Services; [WebService(Namespace
= "http://tempuri.org/")] [WebServiceBinding(ConformsTo
= WsiProfiles.BasicProfile1_1)] [ScriptService] public
class ASPWebService : System.Web.Services.WebService {
[WebMethod] [ScriptMethod(ResponseFormat
= ResponseFormat.Json, UseHttpGet=true)] public
string SayHello() { return "Hello
to Dojo " + DateTime.Now.ToLongDateString();
} }

We also add a [ScriptMethod] attribute to the WebMethod. We do this for two reasons - first, we want to specify that the response  format should be JSON, and we also want to allow access to this method via http Get's (this is disabled by default).

At this point you can hit the web service in your web browser, and get the standard Web Service browser. But if you also stick /js on the end of the url, you will get the client side Javascript that integrates with the MS Ajax Framework. But we're trying to work with Dojo, so we'll move on...

Part 3: Testing the Service in a Browser

Our simple "SayHello" web method does not take any arguments, so we should be able to just "GET" it via a browser.

The tricky bit that took me some time to sleuth down was that you also need to edit web.config to tell the web service to respond to all Gets and Posts. Add this section (just copy out the parts you are missing - do not paste this whole thing into your web.config or you will get an error!):

          <
          system.web
          >
<
          webServices
          >
<
          protocols
          >
<
          add 
          name
          ="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>

Once you do this, you will get the response back. Despite the fact that we have used the [ScriptMethod] attribute to specify that the SayHello web method should return Json, this will only occur if you sent the request content-type to "application/json; charset=utf-8". Without that, you'll still get xml.

Part 4: Create a Simple Page

For this, I created about the simplest page I could - just a button and a div that will be updated. Here's the whole page...

          <!
          DOCTYPE 
          html
PUBLIC 
          "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <
          html 
          xmlns
          ="http://www.w3.org/1999/xhtml">
<
          head
          >
<
          title
          >Dojo
to ASP.NET WebServices</title>
<script type="text/javascript" src="http://o.aolcdn.com/dojo/1.1.1/dojo/dojo.xd.js" djConfig="parseOnLoad:true,
isDebug:true"></script>
<script type="text/javascript">
function updateSampleOne(){ var contentNode
= dojo.byId("sampleone"); dojo.xhrGet({
url: "./ASPWebService.asmx/SayHello",
handleAs: "json", contentType: "application/json;
charset=utf-8", load: function(data,args){contentNode.innerHTML
= data.d;}, error: function(error,args){console.warn("error!",error);}
}); }; </script>
</head>
<body>
<h1>Using
Dojo to Consume ASP.NET JSON WebServices</h1>
<input id="btGetString" type="button" value="Update" onclick="updateSampleOne();"
/> <div id="sampleone">This
will update</div>
</body>
</html>

Breaking down the dojo code...

var contentNode = dojo.byId("sampleone");

This simply get's a the div that we'll be updating.

dojo.xhrGet({
  url: "./ASPWebService.asmx/SayHello",
handleAs: "json", contentType: "application/json;
charset=utf-8", load: function(data,args){contentNode.innerHTML
= data.d;}, error: function(error,args){console.warn("error!",error);}
});

This is the actual ajax xhr request. Since we are using a GET, we are using dojo.xhrGet.

The Url of our web service is the asmx file followed by the name of the web method. Since it's located in the same folder as this html file, we reference it as ./ASPWebService.asmx/SayHello.

The response will be json, so we set handleAs to json

We set the contentType to "application/json; charset=utf-8" as per the ASP.NET security requirements.

When the response returns, we need to do something with it, this is where load comes in. Dojo uses anonymous functions a lot, and for a simple situation like this, it's pretty easy to follow. The returned JSON is:

{"d":"Hello to Dojo Tuesday, June 03, 2008"}.

So we set the contentNode.innerHTML is set to data.d

Should an error occur, the error function is called.

Summary:

So - while this is a little more convoluted than just using the MS Ajax client library and the Script Manager, it does save us from loading multiple client-side frameworks. Since I'm using Dojo for many other UI components, it seemed a waste to also drag along MS Ajax when this is a viable alternative.

One may ask why use the ASP.NET Web Services model? Well, from the server side it's pretty easy to work with. Once a service is created you can access it via Json or SOAP. They are also easy to unit test.

I'll likely extend this with some more complex examples - like submitting a form, or sending / receiving complex types, but I'll leave it here for now.

Download the sample code

While I've messed with the Dojo Toolkit enough to get the interface elements up and running, I've been delegating a lot of the more detailed "wiring" work to Mike- "soon to be blogging"-Juniper, while I worked on the back end web services and database tiers. When I did wire things up, I tended to use the Microsoft Ajax Client-side Library.

Mike is out at Microsoft TechEd this week, so for my current project, I've got no one to lean on, so I'm digging deeper into the Dojo Framework.

For those not in the ArcGIS Server beta program, it's worth noting that the Javascript API that will be shipping with 9.3 is based on Dojo.

Here are a list of resources that I've been using:

SitePen Dojo Quick Start Guide 

Pretty quick read, but covers the main ideas so well that it has apparently replaced the old "Quick Start" guide that was on DojoToolkit.org

Book of Dojo @ DojoToolkit.org

This is a one-stop shop for what's in Dojo. Quality varies between the sections, but overall, a good starting point for what's in there. Covers Dojo, Dijit and DojoX.

Dojo Feature Explorer @DojoCampus.org

This is another good place to see what the controls can do, and you can see the code as well. Again not 100% complete, but covers much of Dojo, Dijit and DojoX.

Articles @ DojoCampus.org

Be sure to check out the articles on the site. They are pretty focused, but well written.

Have some other great Dojo Framework resources? Drop them in the comments!

Newly refreshed after a week of vacation, I thought I'd start things up with the results of the informal "2008 Geospatial Developer Survey". I'll start by thanking the 320 people who took the time to complete it. Admittedly it was a little rough in spots - turns out that writing good survey questions is tougher than you'd think!

Since there were 30 questions in the survey, I'm breaking this into a few posts. As promised, I will post the results as an excel file with the last post.

Who are you?

I thought I should start off the survey with an easy one - what's your role.

The split across titles was somewhat interesting - almost even between "Analysts who write code", and those who consider themselves "GIS Software Developers", with "Software Engineer" trailing slightly. I see this as a progression from "getting things done" coding towards more "built to last" coding.

Primary Development Language

There were a lot of "other" responses on this one, mainly along the lines of "Mix of languages - VB.NET, VBScript, JavaScript, Python, and others".

The idea of this question was to get a feel for what you most commonly work with. I went through the "others" and tabulated them into the mix. Since there were so many variations in the "other" categories, I collapsed them into one group for the pie chart. Perhaps not surprisingly, .NET was the prominent platform with a 61% share.

Here is how the "other" broke out by count of times they were mentioned. I'm pretty surprised that there are still people using VB6 and VBA. While these tools get the job done, the lifecycle for VB6 apps must be coming to a close.

Who do you Develop For?

Almost a 50-50 split on internal vs external clients. Some people were asking why I asked this. I was interested in seeing any relationships between engineering practices and the client base - would there be more advanced software techniques used for the external clients vs internal? With a 50-50 split, it's not entirely obvious, but I've since downloaded the data into a database and I'll try to split out the data a little more to see how this breaks things down.

Use of ESRI GIS Products

This is another question that I got some flak for - but I think it's relevant in that I'm interested in knowing what my readers are using. 40% of the respondents are only using ESRI. Actually I had thought this would be higher - the idea that 60% of respondents are using some mix of non-ESRI GIS tools is very interesting. I'm sure a lot of that is Autodesk stuff, but there's got to be some MapServer, GeoServer, PostGIS and other open source stuff making an appearance in here. Next year I'll change this one up so we can see the mix of packages being used.

Coding Standards

It's nice to see that most respondents have some type of coding standards.

Mostly informal, but that's a start, and if you have a solid team, it's likely all you need. Those folks with out any type of coding standards should really consider setting up something - most languages have some sort of recommendations or conventions. The goal of coding standards is simply to ensure that everyone on your team is writing code in such a way that anyone else on the team can easily tell what's going on. If nothing else - simply using clear names for your variables is a good starting point.

Development Life-Cycles

This was interesting, and will require more analysis, but here's how I look at this. 50% of respondents classified themselves as Developers or Software engineers, and just about 50% also fell into Agile or Waterfall. 30% classified themselves as GIS Analysts who Code, and we see about 35% of cowboy coders.

I'll cut things off here for now - next time I'm going to cover some of the more technical questions - design patterns, unit testing etc. I also need to get the data out of survey monkey in a database format so I can use SQL to tease more information out of the results.

Thanks to Ron Bruder who left a comment on the previous post with the link directly to the documentation for using the PostGIS geometries in the geodatabase. I did have some weirdness trying to access the link - of course you'll need to login because it's still beta documentation, but even after, that I'd see the page, and then it would jump me back to the login screen. I was able to access it by saving the link to Html and then viewing it. Moving on...

Using PostGIS Spatial Format

The ArcSDE doc says that to store data in PostGIS format, you need to create the "database" (presumably the "sde" database) using the postgis template, then create the sde user and sde schema before running the post install. Ok. Since I'd already done this, I dropped the sde database, then re-created it as per the instructions and... yeah.

So the post install failed. It did handily suggest looking at some logs buried away in the sde folder tree, and low the log did have a handy little gem:

db_table_grant_access: Grantee public does not have USAGE permission on schema sde.

Ok. Back into Navicat, grant USAGE to Public on the sde schema, and the post installer is completed. While my end goal is to use Direct Connect, to start, I'm just going to run the SDE service until I know everything else is working.

The next step is to get ArcGIS to use the PostGIS format. For this you need to edit the "dbtune file". From past experience with ArcSDE on SQL Server, I thought that "dbtune" was now a table, and it's a whole lot easier to edit a table than fiddle with the dbtune export/import mess. So, I simply updated the GEOMETRY_STORAGE parameter in the DEFAULTS section of the SDE_DBTUNE table to be "PG_GEOMETRY". So now I should be able to use ArcGIS Desktop to edit / manage data in PostGIS, while still accessing the data as native PostGIS format for say GeoServer and uDig.

Adding and Editing Data

I used the standard Import feature in ArcCatalog, and this worked smoothly. I then fired up uDig to see if it would show up a native PostGIS layer... yep... along with all the other tables in the sde schema. I think that there are likely better ways to organize your data, so this is likely not a "real" issue.

I had some issues applying a thematic renderer to the layer - for some reason it would only apply the renderer to the vectors. When I looked at the SLD xml, everything was setup as a <sld:LineSymbolizer>... since it looks fine in ArcMap (see below), and the original shapefile loads into uDig as polygons, this may be an "beta" issue. Ordinarily I'd check the beta forums right now, but I'm writing this at 38575ft en route to Where 2.0, so that will have to wait. ;-)

Loading data via ArcSDE into ArcMap works very smoothly.

And after telling ArcMap to let me edit "unversioned" data, I could edit as usual. uDig says I can't edit the layer. Being really new to this whole stack, I'm not sure if it's permissions (although I connect as the same identity in ArcMap), or a limitation (heck - I don't even know if uDig can edit vanilla PostGIS layers!)

I also wanted to try a direct connection - I stopped the ArcSDE service. Worked just fine - note the "service" name.

Summary

I've got a few other things I want to mess with, but I've got the basics working. It's been a few miss-steps but not too bad once I read the documentation. Although I've been using ArcSDE on SQL Server for a long time, it's definitely worth reading the docs when setting this up. Clearly I'd need to do more digging on optimizing the database structure, permissions and other sundry tuning things, but if you are looking to trade some time learning PostgreSQL for the $$$ involved buying Oracle or SQL Server, it's pretty compelling. I can't say much about performance as this is just one small layer (US Counties) running on my notebook. I do know people who are running some big databases on PostgreSQL + PostGIS (like millions of spatial features in a layer) and they've got it blazing.

So my company is sending me out to Where 2.0 - I've never been and expect it will be quite different from many of the other GIS conferences I've been to - more MacBooks and soul patches I'm guessing.

I'm particularly excited about the pre-conference workshops, as it will be a chance to get the low down on some technologies I have not worked with in the past.  I'm hitting the Geo-ify your Web Site session in the morning (Mapstraction) and the The Open Geo-Stack: OpenLayers, GeoServer, PostGIS session in the afternoon.

In prep for the workshops I thought I'd get PostGIS (with ArcSDE 9.3 beta) installed on my notebook - ideally I'd like to roll into the session with a little background so I can ask relevant questions!

Installing Postgresql + PostGIS + ArcSDE 9.3 (beta)

Overall, not exactly the smoothest installation I've ever done. No step was particularly difficult, there were just points where I had to do some head scratching, Googling and then "just do it". I have to give ESRI credit as the ArcSDE installer was smooth as silk, and they included Postgresql 8.2 on their media. However, having not used PostGIS before, exactly how this fits into the mix was a little unclear. I will say that if you have used ArcSDE in the past, and just want to get rolling without paying for a database - the install is really pretty easy.

As noted, I installed PostgreSql 8.2 directly from the 9.3 beta media - this is super simple. I then downloaded the PostGIS Installer for PostgreSql 8.2. Again this was pretty easy, after you locate and download it. As per the ArcSDE instructions, I then ran the ESRI post installer, authorized ArcSDE and all looked good.

I could immediately connect to the sde database as the sde user, and used ArcCatalog to load a shapefile into PostGIS. Smooth.

But how do I know that this is actually using "PostGIS"? Would this data be accessible to non-ESRI clients?

Enter uDig. This was a quick and painless install, and uDig was installed.

When I browsed to my local PostGIS server, things were not looking good.

Where was my data? Clearly something is not lining up here. When I tried to connect to ArcSDE via uDig (after I located the jar files) it could not connect. Not sure if this is related to using the beta 9.3 jar files, or something else.

Anyhow, I decided I should try loading the same data via the command line post gis tools. Here I ran into a bit of a wall. The documentation for the PostGIS tools is not bad, but certainly aimed at the unix sys admin type of person. The basic process is to convert your shapefile into a Sql file, and then run that in Postgresql. Seems simple. A quick little batch file ought to work this right out. The sql file was created just fine, but it failed to load.

Sorting this out really meant it was time to do a little learning about Postgresql. After sorting out schemas, and learning that the most likely encoding of my shapefile was "LATIN1" I was able to load my data and "see" it in uDig.

Actual loading the layer into uDig never completed. The application just sort of hung stating that the "Project command" was executing. This was just a map of all the counties in the US, so not sure what the issue was, but I'm pretty sure it was my fault.

I then tried to connect via ArcCatalog to see if I could "see" this layer... and not too surprisingly I could not.

Summary

Thus far I've simply come to realize that I have a lot to learn. I need to grok a lot more about Postgresql and PostGIS to start, and then add ArcSDE into the mix. I'm sure that if I read more of the ESRI documentation I'll find some answers, but at this point it's unclear to me if they will be supporting direct access to PostGIS data, or if they will be supporting the PostGIS spatial format for data stored in traditional ArcSDE schemas (i.e. with all the GDB_ and SDE_ tables). I also learned that I've been sheltered from the reality of "data" for many years!

I'll continue this series as I make progress getting things sorted out.

...from Jeff Atwood author of the (wildly popular) Coding Horror blog. Hopefully you all subscribe to his blog, but for those who may not, it's full of goodness, and you should check it out on a regular basis.

As for MVC - the results of the Geospatial Developer Survey show only about 50% of respondents are using patterns, and about 46% were not using any sort of Model View * patterns. This article is a great entry point to a pattern that can be applied to a very wide range of scenarios (including easing the creation of unit tests!)

Check it out at CodingHorror.com