DDJ Article on MyMap Javascript API

An article in the latest Dr. Dobb’s caught my eye. It’s about MyMap; a javascript api that standardizes the calls between Google Maps, Yahoo Maps and Virtual Earth. I’m always drawn when mapping tools get press outside of the GIS world. MyMap is predicated on the idea that each mapping engine provides similar capabilities. There is a different .js file for each but the function calls are the same. Therefore, it makes it relatively easy to provide similar capabilities for your web app regardless of the back-end engine.

I installed the sample from the DDJ resource center and it’s pretty straightforward. You may need to comment out the call to Google Maps because the API key won’t work for you. If you have your own, you can use that. Either way, the Yahoo and VE calls work fine and give good idea of how MyMap works. I’d recommend checking it out.

zigGIS Now Available!

Paolo moves fast! The new installer is available for download at the zigGIS project home. Bear in mind that zigGIS depends on the ArcObjects .NET libraries. A good post on making sure you’ve got them is available here.

The last version had over 200 downloads. Please feel free to post feedback at the project site. All feedback helps us make it better.

zigGIS Update Coming Soon

Things have been a little slow on the zigGIS front for the last few weeks. Both Paolo and I have been incredibly busy at work. We have both made some updates but it’s been hard to pull them together into a coherent release. That’s getting very close now. Enhancements this time around will include:

  1. On-the-fly reprojection – We have been able to get layers with different SRIDs to overlay correctly. Also, you can change the SRIF of the map and the layers display correctly. Obviously, we haven’t tested every spatial reference out there but we’re encouraged.
  2. Dataset Enumeration – We can now list the PostGIS layers in the database to which we connect. Paolo has implemented a new dialog that allows you to pick the layer you want rather than having to type it.
  3. Use of a PropertySet for workspace properties – It’s now not as tightly coupled to the .zig file and more consistent with how other data sources are implemented in ArcGIS

Paolo is working hard to pull all of our changes together and get a release out soon. There are probably other updates that I’m missing but there will be a full accounting once the release is out. We’re still working toward some bigger issues, such as editing. Also, we’ve begun the development of some catalog objects. Those will be addressed in subsequent releases.

ArcGIS.Next (+)

Steve has blogged about Clint Brown’s talk at the CA/HI/NV/Guam RUG meeting. There’s nothing particularly suprprising but we’re starting to get dates and features tied to version numbers.

I am encouraged that 9.3 will be in beta soon. ESRI’s odd-numbered releases are always more stable. The support for PostgreSQL with ArcSDE is not a surprise. It will be interesting to see whether that ends up being a port of ArcSDE to PostgreSQL or whether they will take advantage of PostGIS. I suspect the former. However, the ability to choose an open-source RDBMS greatly reduces the overall cost of implementing ArcSDE. That can only be a good thing. Also, I’m glad they chose PostgreSQL rather than MySQL. At the risk of slings and arrows, I much prefer PG to MySQL.

I am particularly encouraged by some of the features planned for 10.0. I also don’t see most of those features happening without ArcGIS finally moving away from COM. That will be an extremely welcome change. Hopefully, they will go straight to WPF for the UI.

So what about zigGIS? I see no reason to stop. If ESRI just implements PostGIS, maybe zigGIS becomes redundant but I suspect the GPL will prevent them from doing that. Therefore, I see it being more of a port of the existing ArcSDE. Anyway, I think the need for a completely free connector to PostGIS will continue, so we will keep moving forward.

All in all, I’m encouraged by what’s on the way with regard to the technology. I’d still like to get more of an idea who ESRI’s “Steve Ballmer” is, though.

Two Roads Diverged in a Yellow Wood…

With apologies to the great Robert Frost.

I’ll admit that over the last few months I’ve become something of an open-source convert. I’ve been in the consulting business for about 15 years now and I’ve made through the “holy wars” relatively unscathed (Microsoft/Linux, IE/Netscape/Firefox, Oracle/Everyone else, ad nauseum). I’ve said it before that it’s not religion, it’s technology. I’ve gotten to this particular point in my career with two basic philosophies intact: 1) Nothing big works and 2) I can do whatever you need to do on whatever platform you want with whatever tools you give me; it’s just a matter of “how.”

Most of my GIS consulting work over the years has been with ESRI technologies and it’s served me and my customers well. In general, it works and, more importantly, I know how it works. But over the last couple of years, there has been a disturbing trend with the technology: it’s gotten more complex (nothing big works) and more expensive. When my Federal customers start to balk, I know there’s a problem. In addition, there’s ESRI itself. It is still a privately held company with an owner that’s not getting any younger. Lacking any evidence of a transition plan that maps out how the next 10 to 15 years will go, I’ve begun doing the only responsible thing for my company and my customers: hedging my bets.

Given that most of ESRI’s serious commercial competition imploded years ago (don’t try to debate that with your single-digit-market-share tool of choice), I began paying more attention to open-source products. The approach I’ve taken is to try to piece together an open-source architecture that I would feel as comfortable recommending to a customer as the ESRI architecture. My focus has begun to gel around a core few: GeoServer, SharpMap, PostgreSQL/PostGIS and QGIS. Also key for me is that any client technology must be able to take advantage of Oracle Spatial. It’s not open-source, but it’s everywhere.

Being a programmer from the ArcObjects/ArcSDE mold, the ones I’ve been having the most fun with are SharpMap and PostGIS. As I’ve posted before, I even joined the zigGIS project to enable connectivity between PostGIS and ArcGIS. That’s been the most fun I’ve had in a long time. Probably the weakest link so far is the lack of a really good desktop tool that I could put in front of one of my analysts and say “make a map that looks as good as the ones you make in ArcMap.” QGIS is on the right track but still pretty far from the station. My analysts, thus far, won’t give it a second look.

So how has all of this made me a convert? It’s come down to the simple convenience of open-source. I’m still doing a lot of experimenting. Some of my existing customers are really interested in implementing open-source but can’t quite make the switch yet. So I was playing around with a very simple tool I was trying to build using SharpMap and I just couldn’t get it to work. I figured I had to be doing something wrong so I opened up SharpMap’s source code and examined the class I was using, realized my mistake, and moved on. The power and simplicity of that act, compared to the years of hacking against ArcObjects bugs and documentation, was breathtaking. It’s raised the bar significantly in terms of my expectations of software.

Now to step back from the edge a little: It’s not religion. Most of my customers use, and are committed to, ESRI technology. I’ve had a good working relationship with the company and the people in it. Also, quite frankly, many open-source tools are very immature and unstable. But, as ESRI shifts their focus more to the enterprise market, there will be an increasing number of small of mid-sized users getting into the geospatial game for the first time who will feel priced out. For my part, it would be irresponsible not to be prepared to address their needs with an alternate set of technologies. It will be interesting to see which becomes the road less traveled.

Desktop? We Don’t Need No Stinkin’ Desktop!

I figured I’d pile on here because it seems that a little ganging up may be in order. James and Kirk have posted about the dearth of Desktop sessions at the upcoming Developer Summit.

Kirk also provides a good, specific example of a server-only feature that would be useful, and perfectly possible, in Desktop. One of the big advantages to having a product like ArcGIS Server which, like Engine and Desktop, is built from ArcObjects, is that you can have the same core set of objects to use to build applications in all three environments. Yes, there will be some peculiarities to each platform (especially Server) that dictate some special cases but, really, something like the FeatureGraphicsLayer that Kirk points out should be available in all cases.

ArcObjects is a behemoth and ESRI’s challenge will be not to fork the code base unnecessarily along platform lines. I realize Server is the cool kid on the block right now but Desktop is going to be the workhorse for a long time. ESRI needs to make sure it doesn’t get left behind at the API level.