The FedUC Approaches

The ESRI Federal User Conference is almost here. I’ll be going this year because my company is doing a booth. I like to refer to this event as the “UC-Lite” in that it’s smaller and more focused.

I highly encourage anyone in the DC/MD/VA region to go. First of all, admission is free to all federal employees and it’s only $100 for state and local employees. If you can take the time and have the travel budget, I’d say go. Although, it’s the “Federal” UC, there’s enough general exposure to ESRI technology that this event is a nice alternative for those who can’t make San Diego. Basically, you see a lot of government applications of the technology but the concepts will cross over well to other markets and applications.

Of course, this event occurs in my back yard so I’d like to see it thrive. See ya in DC…

Happy New Year and a Continued Merry Christmas

Greetings to all and wishes for a peaceful and prosperous 2007. And, for those of you keeping track at home, today would be “seven swans a-swimming”.

I’m heading out for a business trip tomorrow that keeps me gone for the rest of the week so it’s time to pack away the decorations. Typically, we wait until after Three King’s Day but my travel schedule won’t allow for that this year.

zigGIS and Spatial References, Part 2

Update to this post:

Another post about zigGIS. I didn’t really intend this blog to be so dominated by zigGIS but that’s certainly the way it’s been thus far. Basically, it’s just really cool and it satisfies my geek nature on a couple of fronts.

After posting about the spatial reference issue before, I couldn’t resist digging into it. I found a placeholder in the implementation of IFeatureClass. Abe G. had even left a comment there that he needed to go back and implement it. So I dove in…

In the IFeatureClass implementation of CPostGisFeatureClass the SpatialReference property was stubbed out to always return and UnknownCoordinateSystem object. The feature class wraps a CLayer object (among others). This is the object I needed to use to get the spatial reference. The loadLayer method of CLayer (in the postgis_connector project) contained the following code:

string sql = CDbHelper.createSelectSql
(CPostGisConstants.geometryColumnsTable + " as g",
"g.*,g.oid,s." + CPostGisConstants.spatialReferenceSrField,
"left join " + CPostGisConstants.spatialReferenceTable + 
" as s on g." +
CPostGisConstants.spatialReferenceIdField + "=s." +

This code queries the geometry_columns table for all of the metadata I need. So I added the following code to the CLayer class:

private int m_srid = -1;
public int srid { get { return m_srid; } }

I then added this code to the loadLayer method…

m_srid = (int)((Int32)dr["srid"]);

…in order to expose the srid for the layer. The variable dr refers to an instance of the CAutoDataReader class defined in the postgis_connector project.

Finally, i added the following code to the init method of the CPostGisFeatureClass class in the postgis_geodatabase project:

if (m_layer.srid != -1)
    ISpatialReferenceFactory2 srfact = new SpatialReferenceEnvironmentClass();
    m_spaRef = srfact.CreateSpatialReference(m_layer.srid);

With that, the layer properties dialog in ArcMap correctly reports my spatial reference and the geometry that once failed to draw now works fine. I’ve got some more clean-up to do to the code to add some error-handling and the like. I’m sure it wouldn’t take much to crash it right now.

I think the thing I like about zigGIS is that it’s got something for everyone. ArcObjects geeks will appreciate the implementation of feature classes, cursors and the like. .NET geeks will appreciate nuggets like the CAutoDataReader class which is an implementation of the IDataReader interface. All in all, it’s a nice piece of work that I find more to like about as I dig deeper.

As I mentioned before, the project has a new home in Google Code and the discussion forum is getting a little more active so maybe zigGIS will gain a little more momentum. That’s all for now…

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.