ESRI, MapObjects and .NET

As I’ve posted here a couple times, we are looking at moving to a complete .NET environment. We’ve not really decided on what tools we’ll use, but that will come probably after we start testing ArcEngine.

I was researching some .NET threads on ESRI’s support site while floating in the pool on a Memorial Day weekend and say this amusing thread over at the ESRI Support site:

Mapobjects dot net version (dead link)

I can’t imagine how frustrating it must be having to explain to people how many COM programmers there are out there in this world. We are moving to .NET, mostly because my programmers prefer the .NET components over COM. We’ve talked about this at great lengths and we plan to keep our maintenance current on MapObjects for at least the next year and most likely until they abandon it because we just don’t see COM going away. BUT, reading the tread there at ESRI, you have to wonder why the “average” ESRI Developer would even think so. Lets just ignore that there are still tons of VB6 and Delphi programmers out there with no plans to move to .NET and focus upon VBA. We’ve created many programs for our clients using Microsoft Access as most people are very comfortable in it. Adding a simple map to is easy using MapObjects and I can’t imagine having to create a .NET application to do the same thing. VBA, while not one of my favorite development environments, is going to be here for years to come. Yet people seem to think that just because Microsoft is pushing .NET, that COM will go away.

The future is murky when it comes to programming languages. What is popular one year, becomes forgotten the next. If I was a betting man though, I’d assume COM will be around for years to come and probably in one for or another might even outlast .NET. For some of these VB6 programmers, you’ll never get them to upgrade to .NET and why should they? Simple is better, I’d take a small footprint (in file size and memory) COM program, over a bulky .NET application almost every day.

ESRI ArcGIS 9.1 is here

Of course UPS shows up at 5pm on the Friday before a 3 day weekend. Somehow I was able to not stay late and install ArcINFO, ArcIMS and ArcSDE 9.1 to play with. I must be getting older and wiser as this doesn’t sound a thing like me.

I’ll have to wait until Tuesday to see what happens.

RSS Feeds for ESRI

Tucked down in a post about Federal Computer Weekly, Brian Goldin wrote:

Speaking of RSS – anyone want more RSS reeds at ESRI? How about on the EDN site? If you haven’t noticed Microsoft has just added 100s of knowledgebase rss feeds.

I’ve always thought ESRI has been a little behind the times with their websites. It took forever for them to put the knowlegebase online and they still release news by email. It should be as simple as publishing an RSS feed and letting all of us read is immediately. Hopefully they’ll get on board as it doesn’t take much to publish the feed and we all know ESRI has some pretty bright XML programmers over there.

The Carbon Project

We’ve been working on MapObjects application in .NET this past month, trying to see how it would work using some COM objects (previously we’ve always just used VB6). While it seems to have worked well enough, getting it to deploy has been quite a pain. We just can’t seem to get the MO runtime to work well enough with the default Visual Studio installer or even the InstallShield installer. ESRI has been a little help, but we just can’t seem to pin down the problem. My programmer came up with a solution using a batch file to run the MO runtime, then install our product. It works, but I’d like to think in 2005 we could get away from using batch files for installation. I came across a .NET freeware project called The Carbon Project which seems to be closer to what we want, a pure .NET solution. We’ve looked at ArcEngine, but until we get our ESRI Developer Network license paid for, we just can’t afford to buy it. I had my programmer contact some of the developers on The Carbon Project to see if it could do what we wish. He wrote:

how you can take one polygon, overlay it with another, and get either the area inclusive the two (intersection), the area non-inclusive of the two (clip), the area contained in the first but only that which overlays from the second (identifying), or the total area from both (union).

That is all we really want with this application. Something that us GIS folks have been doing since the beginning of time. MapObjects LT can’t do it, but MapObjects 2.3 can. One of the team members of The Carbon Project quickly wrote back:

We have not yet implemented advance geometry manipulations in CarbonTools. I’m sure that there are some source samples on the Web for implementing some of the more common algorithms. If you are up to the challenge and come up with code to resolve some of the issues you described, we would love to share them with our community of users. Hopefully in future versions of CarbonTools we will implement some advanced geometry work (not in the near release of beta 3 however).

Damn, so close. While we’d love to see if we could do it (and we still might) our little application is due early next week. Looks like the batch file install is going to be it.

So what can I learn from this? Well while MapObjects is still a great platform, we’ve move beyond COM and I think we’ll have to leave it in the dust. Not my first choice, but for ease of use, I’d love to keep all .NET code. Also, we’ll want to keep on top of The Carbon Project to see if when we have somedown-time, we can possible do what we want. I really wish they had a RSS feed so I know I won’t miss anything. When we finally get our ESRI Developer Network subscription, we’ll be able to check out ArcEngine and see if it can help us out. I’m just concerned with how the licensing will work with it. We’ll just have to wait and see.

Designing a front end

I manage a GIS at a small company in Tempe, AZ. We’ve been designing web based GIS sites since the old ArcView IMS extension. We’ve moved from MapObjects IMS to ArcIMS 3,4,9 and now we’ve begun to look at UMN Mapserver. Basically we’ve heard from clients that they are having problems with the cost of maintenance of ESRI products. If we could eliminate ArcIMS/ArcSDE for these people and still provide our look and feel, this might be a market worth looking into. I’d love to make our sites work with any backend that the client wants. We’ve used .NET in our latest products, but maybe PHP or JSP would be a better choice for doing this. I’m just not sure what to think at this point, but I’ve got our database programmer looking at getting PostGIS and Mapserver installed on our Linux server.

It’s going to be quite a move from ArcIMS/ArcSDE/Oracle, but maybe we’ll learn something. I’ll post more about this next week when we get it installed.