Why Isn’t ArcGIS Explorer Open Source?

I was tinkering with AGX today, mainly trying to get comfortable with the API. As I was playing with it, this thought crept into my head: Why isn’t this thing open source? Okay, aside from the fact that it was released by ESRI…

There are two main reasons that I ponder this: First, it’s already free. ESRI isn’t charging for it so it’s essentially a cost sink for them. ESRI still incurs all of the costs associated with lifecycle maintenance with no direct recovery of those costs. Yes, I know that they are diffused across the revenue streams of the rest of the product line but bear with me. One could make a strong case that by making AGX open-source, ESRI’s overall costs would go down. Right now, they shoulder 100% of the cost. By opening up the product to a community of developers, that cost would go down. Basically, I don’t think that a free, closed-source AGX is going give ESRI much traction anywhere so you could call this the “what-have-they-got-to-lose” argument.

Secondly, there’s Google Earth. I will say right now that GE is a superior product to AGX. I won’t even try to debate otherwise. That said, AGX is pretty good. I know that ESRI has said that AGX is not intended to compete with GE. It’s targeted at the enterprise environment where it would be the “spinny globe” client to their server software. This is precisely the environment where GE starts to cost a good bit of money. By taking AGX open-source, ESRI could accelerate the advancement of the product while reducing costs and have it remain competitive. I think AGX will go over just fine in shops that are already using ESRI’s software but I don’t think it’s compelling enough to expand their market on its own. But, with its ability to consume KML, WMS, ArcIMS and ArcGIS Server as well as with its API; AGX has got a little game. Taking it open-source could potentially open up a whole new community of advocates who would have a little pride of ownership.

There are other smaller reasons to do it as well. ESRI has started dabbling in the open-source world with the 52 North initiative. Opening the source to AGX would certainly demonstrate commitment there. Also, this particular market segment is crowded: GE, AGX, World Wind, Virtual Earth 3D. AGX, as it stands now, adds little to the picture. An open-source AGX would at least add something to the community.

The main downside would be the difficulty in synchronizing the activity of an open-source project with the release schedule of ArcGIS. In addition, ESRI could risk losing control of the product altogether but there are enough models of open-source projects with corporate backing, such as Eclipse, to work from.

So, maybe it makes sense and maybe not. I could probably argue it either way for quite a while. AGX plugs a gap in the ESRI product line that’s existed for a long time and maybe that’s good enough for them. It’s most likely a complete non-starter. But again, it’s a free product. So, if it’s free, maybe it should be set free.

zigGIS on Google Code

It seems this is quickly turning into the zigGIS blog. Anyway, it appears that Paolo Corti has assumed the role of project lead on zigGIS and has moved it to Google Code. I’m excited because I think this is a great project and this should keep it moving forward. There’s also a group for discussing the project.

Thanks to Abe Gillespie and Paolo for collaborating to keep zigGIS going.

zigGIS and Spatial References

I’m still playing around with zigGIS and I have noticed that it doesn’t seem to play well when I define the spatial reference of a data set in PostGIS. Any data set that has a defined spatial reference fails to draw in ArcMap. In addition, the layer properties always indicate that the coordinate system is undefined, whether on exists or not. This leads me to belienve that zigGIS is not handling the spatial references well.

As you can see, the dtl_st layer does not draw in ArcMap. I imported it into PostGIS using shp2pgsql with an SRID of 4326 (WGS84). The others layers were loaded with an SRID of -1.

As shown, the layer draws fine in QGIS. I will need to dig into the zigGIS code a little more to see about this one.

PostGIS and ArcGIS 9.1

I’ve been intrigued for some time by an open-source (GPL) project out there called zigGIS. It is a C# project that enables a direct read of PostGIS by ArcGIS. It is intriguing for a couple of reasons. First is the promise of reading directly from PostGIS and working with your data in ArcMap without the need to create intermediate shapefiles or some other ESRI-friendly data format. Second is the fact that the project is a good example of the “correct” way to extend data support in ArcGIS. That’s to say the authors built the necessary workspace, feature class, and cursor objects to behave like any other set of geodatabase objects. As an ArcObjects developer, having a working example of this, with source code, was irresistable.

I had originally downloaded it about a year ago but let it sit because it only supported ArcGIS 8.x. I recently went back to it discover an updated version but still only 8.x support. I had a little more time on my hands this time and decided to do the upgrade to 9.1 myself.

The ArcObjects upgrade was fairly painless but I’ve done that a few times now. I found the documentation to be a little thin on some of the project’s dependencies. Specifically, there are several external open-source projects that zigGIS is dependent upon: log4net, npgsql, nini. While the readme specifies these, it doesn’t mention version numbers. This created the greatest issue with npgsql due to the fact that the zigGIS developers build a custom version for zigGIS.

The install instructions indicate that you should get npgsql from the pgFoundry and then replace the DLL with custom one for zigGIS. The problem arose from the fact that npgsql has been updated and it also has a dependency on Mono.Security.dll. The latest version of npgsql.dll uses version 2.0 of Mono.Security.dll but the version used by zigGIS uses version 1.0.5 of Mono.Security.

Once I sorted this out, I used the ESRI developer tools to remove references to ESRI.ArcObjects.Core and replace them with the necessary 9.1 libraries. ZigGIS comes with a VS2005 solution but I highly recommend following the developers’ instructions and using nant to do your build. They provide their build script and it needs to be updated for 9.1 but it works great. The cursor and geodatabase projects introduce the kind of circular references that Visual Studio doesn’t like but that nant handles nicely.

POSTGIS Data in ArcMap with identify window. After I got the project to build, I was able to access data directly from PostGIS. This screen shot shows a sample data set in ArcMap. I’m running PostgreSQL 8.2 with PostGIS 1.2.0 on a Windows XP box. I loaded this data into PostGIS using the shp2pgsql utility that ships with PostGIS. The utility of zigGIS is readily apparent but its approach holds wider promise. There are numerous other data sources and open-source projects that could be integrated using the approach the zigGIS team has laid out here. MITAB is one that springs to mind.

Despite some of the issues I had with the build process, I got the project up and running in less than a day. Given the results, that seems like a worthy investment of time.

Good Article on Optimizing Open-Source Software

There’s been a lot of recent buzz about open-source GIS software. Good discussions can be found at James Fee’s site, plus Datum Shift as well as on Dave Bouwman’s blog.

Given all of this discussion, I found this article in Dr. Dobb’s Journal to be rather timely. It’s not about GIS software per se but it’s definitely relevant.

DDJ has undergone some changes of late but I still find it incredibly informative. That said, I still miss opening it up to find Verity Stob.

IRasterLayer Export Gotcha in 9.2

Not long ago, I was working on a project that required us to convert our rasters from their native format (mostly CADRG) to TIFF. We need to do do this because we were viewing them in a .NET 3.0 WPF control so we needed a format it could recognize.

At the outset, we were using Engine 9.1 and settled upon using the IRasterLayerExport.Export method. The choice of TIFF was driven by the fact that, at 9.1, it was the only output format this method supported that could be read by WPF. Everything worked fine. For those of you unfamiliar with this method, here is our call (abridged):

rasterLayerExport = new RasterLayerExportClass();
rasterLayerExport.RasterLayer = exportRasterLayer;
rasterLayerExport.Force2RGB = true;
rasterLayerExport.Export((IWorkspace)ws, outputName, “TIFF”);

About half-way through (for a number of reasons), we upgraded to 9.2. It was at this point that we noticed that the TIFFs we were generating were no longer readable by WPF. After some research, we discovered that, instaed of a standard TIFF, this method now exports a GeoTIFF. The extra header information throws off WPF.

The good news? The IRasterLayerExport.Export method now supports many more output formats. We updated our code to export out to PNG and kept going.

All in all, I think the changes to this method are a net plus but I wanted to share that little gotcha. If you’ve been using it to export to external graphic applications, you’ll want to do some testing.