Spatially Adjusted

Tag: mapobjects

  • Bad Esri Products are Good

    I was having drinks the other day with an ex-Esri employee and we were talking about what Esri products I liked to work with. The short list is right below:

    1. ArcView 3.x
    2. MapObjects
    3. ArcIMS

    Arc/INFO might be on that list but let’s cap it at three. None of them were products that Esri wanted to keep around. All of them were thrust in the marketplace and then poorly supported. I get the idea that Esri wanted everything on ArcGIS platform (Server being a joke for so many years is proof of this) but being a developer on those platforms was really hard. The transition from Avenue to VB/VBA was particularly brutal. There were books written to help with this transition, but none by Esri.

    My trajectory was shaped by these products above being abandoned by Esri. I went another direction because of being burnt by proprietary products that when abandoned cause huge problems. I think you have two choices, either double down or hit the eject button. I’m so glad I ejected…

  • MapObjects to the Rescue

    We’ve pretty much just finished up a rush job given to us by a client to create a tool to allow planners to see where constraints (man-made and natural) are located on their property. This had to be done in such a quick time we were really concerned how we’d be able to pull it off. Thank God for Map Objects. I’ve always like the object model in MO and how easy and quickly one can develop applications. I’ve lost count on home many MO and MOLT. It is a shame these products are being “phased” out as ESRI transitions to ArcGIS Engine/ArcObjects. Dealing with COM and .NET in the same application is a mess sometimes, so I can understand why MO is being put on the back burner. There are many of us who really cut our teeth on GIS programming using MO and even Avenue over the years and there has to be a point that one walks away from these two “development environments” but if I have any say over it I’ll still be using both (especially MO and MOLT) for years to come.

  • Moving away from web based GIS

    I’ve noticed an interesting trend during the last year with our clients. Many of them have decided that internally they don’t want web based ESRI ArcIMS or similar products. We’ve worked with them to create either stand alone ESRI MapObjects applications (hopefully we’ll upgrade them to ESRI ArcGIS Engine soon) or just using ESRI ArcPublisher and ESRI ArcReader. The MapObjects applications have been more geared at management who need access to the GIS information, but not the complexity. These applications usually answer “what if” scenarios that we used to program via the web. The clients who request them don’t have or don’t want to invest the money in server side (hardware and software) GIS. Most if not all of the ArcReader implementations we’ve done use ArcSDE to store the data (some even use ArcIMS services). These clients seem to want the added cartography options that can be created with ArcMap that we’ve never really been able to get programming AXL. Printing has also been an issue. While we’ve gotten pretty good with some of our layouts on the web, they just don’t look like the ArcMap products that their GIS teams are creating. With ArcPublisher they can have the exact map their GIS analysts are working on. I’ve just received an RFP from one client that wants to look into the new ArcGlobe features of ArcPublisher which should be perfect for displaying what they want.

    I’ve always pushed web based GIS because you don’t need to install software to gain value from it. But it seems with today’s managed computer installs, rolling out ArcReader to all clients isn’t as difficult as it once was. I will say the one feature that ArcPublisher/Reader still doesn’t have is a better “pack and go”. I’d love to see a way to embed the GIS layers in the PMF so that you only need one file to send to people. PDF is a pretty good solution, but sometimes you just want to grab that ID tool and see exactly what the database behind a layer is hiding. Oh well, maybe ESRI ArcGIS 10?

    We are still developing web based solutions for clients and are even currently working on an open source solution. I just think some people have been burned by overly complex websites in the past and don’t want the overhead of maintaining them or dealing with another department that might control the webservers.

  • 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.

  • 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.