Fighting Manifold (or Fighting the Way I’ve Learned GIS)

I feel like I have to forget everything I know about using GIS when I’m in Manifold. I’ll be honest, I can’t figure anything out without the help. Everything I know seems to be done differently. Based on a couple of folks suggestion, I’m going to be going over the GISAdvisor videos to see if that can help.

I will say the videos I’ve looked at are very well produced so I can see how Manifold users view them as a great resource. Maybe this will help me get back on track.

DISCLOSURE – This copy of Manifold was provided to me by Manifold for evaluation.

108 Comments

  1. Anon says:

    So wait? I spend almost 1/3rd the total price on Manifold just to get help.

    What a POS.

    James I see how you are trying to be fair here, but you are not fooling anyone. Manifold just sucks for GIS pros and there is nothing a movie can do to help that.

  2. mdsumner says:

    You paid for something without getting a free demo? Or was the SQL video enough?

    ;)

  3. Petz says:

    I think there is a deep misunderstanding about the word GIS here. For most people I believe, including James here, when they say GIS, what they really mean is ESRI ArcGIS. I believe that GIS knowledge and expertise should be generic enough to be not specific to a set of software tools.
    So James you really are struggling with finding the buttons so to speak, not with using GIS as defined above.

  4. Chad says:

    From what James has been talling me.. anyone coming from ANY other GIS package will have a verticle wall of a learning curve when trying Manifold.

    From what I have heard from people Manifold went out of it’s way to 1) call things different names from what everyone else calls it and 2) just does things differently from all other GIS packages.

    I have used uDig and QGis and with 5 minutes I had worked out how to create a basic map, something he had a hard time working out at first. I have not used Manifold (no time limited demo makes them unapproachable and I am not going to spend money to see if I like the program or not) so I can’t say if I would pick it up or not… but looking at what James posted and the screen shots.. it would have taken me a lot longer than 5 minutes.

    So, I think James is mostly correct.. when going to Manifold you have to forget most anything you did before with most apps and learn it the “Manifold Way”.

  5. AnonNut says:

    So wait? I spend almost 1/3rd the total price on Manifold just to get help.

    what an idiot! The reason why the training is 1/3 is because Manifold itself is so inexpensive. $400 vs. $22,000 (ArcGIS + ArcIMS).

    What does an ESRI class cost? – thousands!
    What does an ESRI virtual campus course cost? – hundreds! Plus, how much material does a virtual campus course actually cover.

    the videos, which I’ve learned from, cost under $100, and as they say, is equivalent material in a 4 day training class.

    How did you learn ArcGIS – on your own? Probably not. Even if you bought a book, you paid $60.

    Manifold just sucks for GIS pros

    Petz is correct, you are equating GIS with ArcInfo. Wrong move. GIS is about spatially enabling technologies, plain and simple. And yes, Manifold is a different paradigm.

    I think James is being very fair. He’s doing his best to learn a sophisticated product. Would you just pick up Oracle or Sybase and try to learn it? How about C#? If you were smart, you’d invest a little money into training.

    You also have to admire James’ integrity. Rather than flip the bozo bit on Manifold, he is doing his due diligence to learn the product to give an honest appraisal.

    I know you have a religous conviction about ESRI, so I understand that you haven’t used Manifold but hate it. Thats ok, religous zealots are like that.

  6. geoblc says:

    The GISAdvisor videos were a great help to me – once I got past the monotone narration. You can’t beat them for the price. Another thing I found helpful, although it’s now a bit dated, was the paper “How do I do that in ArcGIS/Manifold: illustrating classic GIS tasks” edited by Arthur Lembo at Cornell University. It’s probably still available.

  7. Jerome says:

    None of James’ conclusions should come as a great shock. Reviews dating back to 1999 had the same issues! For example, see Adena’s conclusion in her review of version 4.5:

    “Manifold is a fine package, though hardly a ‘beginner GIS.’ There is quite a lot of power here and it takes time to learn and use. In one sense existing GIS users will have to ‘forget what they know’ to grasp the Manifold way of doing things. There is no question that this is the best value in GIS. Just be prepared to study hard master its full potential.”
    http://www.gisvisionmag.com/vision.php?article=%2FGISVision%2FReview%2FManifold.html

  8. Christopher says:

    Our company has both Manifold and ArcGIS. We use ArcGIS for most of our projects except for one where a client uses Manifold and wants everything done “that way”.

    Frankly to me ArcGIS is more intuative and I didn’t learn it before getting this job. I worked with CAD before GIS, so maybe that is why ArcGIS makes “more sense”.

    I do understand how price comes into the equation so I can’t really argue that when you factor in cost, Manifold might be the better choice for some people. It is an aquired taste and we have people in our company that prefer it to ArcGIS.

    I’m just not a huge fan.

  9. InverseAnnoNut says:

    what an idiot! The reason why the training is 1/3 is because Manifold itself is so inexpensive. $400 vs. $22,000 (ArcGIS + ArcIMS).

    I think that cost isn’t particually fair to ArcGIS as this really isn’t an apple and apples comparison. I think James said before Manifold was an 80% solution at 20% of the price. That might be a better way of putting it. If you need that extra 20% that ESRI can get you, you have to fork out big bucks to get it, but at least you can get it if you want.

    What I’ve noticed at Manifold is that its support is less than steller. I have to pay for telephone support which to me is baffleing. With professional products, I expect professional support. We don’t have ESRI anymore because we couldn’t afford the maintenance, but we do use Autocad Map and Manifold. I find myself using Map more than I use Manifold as time goes on because of the better support that Autodesk gives me.

  10. Chris C. says:

    The cost of the training videos is very good value – as James said he’s finding Manifold quite alien compared to ‘standard’ GIS – the videos will get him up to speed qucker than trawling through Help.

    How much does it cost to get an introductory course for ArcGIS – around $2000 – and do you get a training video thrown in to refer to? With GISAdvisors videos you get hands on examples that you can refer to again and again.

  11. James Fee says:

    I think there is a deep misunderstanding about the word GIS here. For most people I believe, including James here, when they say GIS, what they really mean is ESRI ArcGIS.

    Petz, I did say “the WAY I learned GIS”. When I say GIS I mean anything from Autodesk to Zillow (give me a break, that was the first “Z” I could think of off the top of my head). I’m not saying the way I do GIS is right or wrong, just different from the Manifold workflow.

  12. Jack Dangermond says:

    Here’s the paper on how to do 100 tasks in ArcGIS & Manifold…
    http://dspace.library.cornell.edu/handle/1813/165

  13. Jesse says:

    James, I applaud you for really attempting to wrap your head around Manifold. Personally, I’m curious to know how well Manifold handles data management and more “heavy-duty” geoprocessing and analysis.

  14. Matt Priour says:

    @Jack:Thanks for the link, I also posted that on my blog a while back, and have found it helpful.

    I think what bothers me most about Manifold is the attitude and tone of the documentation and their insistance that the Manifold way is the right way and you better go to school on it or keep your mouth shut.

    I’ve intuatively taught myself a whole bunch or very complex software and concepts including ArcGIS, ArcView 3.x, Visual Studio, VB.Net, C#, PHP, CSS, and many other less complex things.
    In all of these instances, I was able to look at the menus or overview documentation, begin working, and lookup the help or reference docs when I got stuck. Read a bit, experiment a bit, solve it, and keep on going. My early uses of these software packages and languages was on a fairly simple “use this tool to solve this problem” level. However, because I was able to intuatively learn from working and experimenting, I continually expanded my knowledge and areas of use each time to try to realize the full power of each system.
    If I can’t do that kind of learning with Manifold, I don’t think that it means that your product is superior and only for “serious” users. I think it means that you have a poorly designed UI, workflow process, and have probably not done much true usability testing. I’m not saying it needs to be dumbed down (ESRI’s stuff certainly isn’t). It just means that if you want to convert the masses tried of having to shell out big $$$ for a comphrensive GIS system, you should be mindful of where they are coming from and design workflows and UI elements that are less purpusely foriegn.
    Matt

  15. manifolduser says:

    Matt,

    I don’t want to sound like some total wise-asx, but when I got Manifold, it only took me two days to learn it. I did what they said: I read through the Help files. Now, I’ve been using GIS for 20 years, so maybe I had a little head start on others.

    The real issue for me was the first 15 minutes (I almost quit!). I was looking for the familiar ESRI plus sign at the top. I didn’t see it, and though what a POS. But, I was desparate since my ArcIMS stuff was going nowhere.

    So, I looked in the help manual and there it was: the key to bringing in a file. After I did that, all was great, and within one week, my IMS site was doing more than my ArcIMS application did after 6 months of development.

    But, the reality was, I almost threw up my hands after the first 15 minutes. That first hump is the worst. I’m glad I didn’t quit. Eventually, the gisadvisor.com videos came out, but I was already pretty used to the product.

    All this to say that Manifold was really easy to learn, even without the video training. But, it did require me to have to unlearn some ESRI workflow stuff. Now, I see the ESRI workflow as wasteful – here I’m probably just overreacting. But, I would much rather use Manifold than ESRI software. I can do things in at least 1/4 of the time with Manifold, the SQL abilities, the cut/paste stuff, the dynamic geometry, etc.

  16. James Fee says:

    Now, I’ve been using GIS for 20 years, so maybe I had a little head start on others.

    That extra 5 years must be making the difference. ;)

    My problem is I don’t find the workflow similar to anything I’ve ever used. ESRI, Autodesk, Mapinfo, Intergraph, Adobe, etc. I don’t find this to be a classic windows interface.

    That said, I’m beginning to get a hang of it so we’ll see what I can do with it.

  17. miketel says:

    I’ll tell you the part that annoys me the most about manifold is the toolbars. I find them overwhelming and not helpful.

    Manifold was described to me as Microsoft Office for GIS and I never get that feeling when I’m in it.

  18. JoeGIS says:

    Why would I use a two-bit program like Manifold when there are so many other industry standard ones. From ESRI to Intergraph there are much better choices to invest your money in. If you are just looking at the cost of the software as a gage, then you are missing the big picture.

    I can’t imagine a world where someone sends me a .map file instead of a Geodatabase or shapfile. Manifold is the Lotus 1-2-3 of the GIS world. Weird for the sake of being weird.

    Microsoft when they began to fight back against Wordperfect offered up ways to learn. Manifold seems to live by making their product difficult to compensate for something I just can’t figure out.

  19. Lokai says:

    Why is it whenever I hear about people learning Manifold, I hear how hard it is to use.

    Manifold seems to relish in difficulty rather than ease of use.

  20. KoS says:

    ArcGIS and Manifold both suck. :)

    ArcInfo workstation line commands is the only way to go!

    KoS

  21. Dimitri says:

    Some random responses…

    “Manifold was an 80% solution at 20% of the price.”

    Let’s not be arithmetically challenged: $395 is not “20%” of $22,000. It’s more like 2%.

    Also, the “80%” is not exactly on point. Any of the very big GIS systems have thousands of features. They all do something the others do not. So there are many things in Manifold that ESRI does not do: a good spatial SQL, the ability to script in .NET or ActiveX languages, Active Columns, Viewbots, neurofuzzy logic, numerous formats, a GPS console, image server modules and so on. So, do you refer to the Arc suite as delivering only 50% of what Manifold does? That is, would you characterize the arcstuff as a “50% solution at fifty times the price?” No. The difference in price is what it is, but as far as feature set is concerned all that matters is how any particular feature set matches what you require.

    “Manifold seems to relish in difficulty rather than ease of use.”

    ??? Don’t know where you get that. Manifold is straightforward and easy to learn. Because of the low price we have plenty of people who have never done GIS before who learn and use it just fine.

    There are a few notes in the manual advising people not to skimp on paying attention. This is fair game, as some folks think that just because something is relatively inexpensive it is a toy. So it is helpful to alert them to the content, to give them a chance to work in their own interests.

    Even with that advice there is a lot to consider: a typical Manif0ld package includes capabilities to work with vector data, images and image editing, surfaces, 3D terrains, DBMS, internet map server, sophisticated DBMS, a full development environment (syntax-colored editor, debugger, a variety of common objects, ActiveX languages, .NET languages), extensive SQL, fuzzy logic subsystem, charting, active columns, geocoding, analytics of endless kinds… well, that’s a lot of stuff to cover and even subsets of it like the DBMS capabilities could occupy a book.

    So show some respect for the subject matter and for the intelligence of people who want to work with such rich capabilities. None of this is for imbeciles. Software for working simultaeously with such a wide range of capabilities, as demanded by the very intelligent people (the users) who are doing the demanding, is not mindless stuff. It has many nuances and requires some non-trivial reflection.

    So no, Manifold is not somehow relishing unnecessary complications. But it is responsive to the nuanced understandings of the user community that drives development of the product. And those people are neither fools nor are they interested in suffering with unsophisticated controls or interfaces.

    To be blunt about the matter, usually when I hear someone complaining about one thing or the other being unnecessarily complicated, upon taking a closer look what is going on is someone who does not have the sophistication to grasp why more expert users demand a finer level of control. Explain the nuances and the new user often remarks “ah yes, I see now why that is that way.”

  22. Dimitri says:

    Dang… how could I forget?…

    “What I’ve noticed at Manifold is that its support is less than steller. I have to pay for telephone support which to me is baffleing. With professional products, I expect professional support. We don’t have ESRI anymore because we couldn’t afford the maintenance,”

    Amazing how much pretzel logic can be stuffed into a few lines.

    “its support is less than steller” – well, if you did not buy support you are not using it. Are you saying you bought support and that it was less than stellar? Probably not. What you probably meant is that Manifold support is brilliant, amazingly expert, but that for some incredibly inefficient emotional reason you chose not to purchase it for the absurdly low price it costs.

    This is a bit like the guy who doesn’t buy a BMW automobile who says “BMW is less than stellar ” when what he really means is that “I didn’t buy a Beemer so doing without is less than stellar.”

    At manifold.net the very same engineers who develop the product get rotated into assignments to do technical support. This assures that tech support incidents are processed by total, maximum experts, the people who actually have created some part of Manifold. It also provides plenty of “real world” experience so that when engineers go back to doing development they have truly internalized the need to create things that are supportable. After all, one day they could themselves be supporting the product they create.

    “With professional products, I expect professional support.” Given so much manly “professional” talk I presume you are not going to weasel out on us by suggesting that you have no intention of paying for the professional services you consume? I mean, let the testosterone flow if that’s what you want to declare, but if you’re going to put on your “professional” hat you do realize that what differentiates a professional from an amateur is the payment of money, right? How is it that you want to pay that money?

    What do you think is better – to pay for professional services as you want them, or would you rather give that big, evil GIS company a huge wad of cash in advance that is calculated to pay for the least common denominator cost of imbeciles who won’t read documentation, haven’t invested in GIS education and don’t know squat about anything as much as you? If it’s the latter, no problem: go get your forklift and empty out your bank account to give more money to ESRI. If it is the former, choose Manifold and spend whatever you want on whatever professional service you require when you require it. If you’re a smart, alert guy and don’t need hand-holding like some guys do, you’ll be glad you’re not paying for someone else’s services.

    “We don’t have ESRI anymore because we couldn’t afford the maintenance,” Sarcasm fails me at the perfect irony of that comment in connection with a complaint that tech support is not “free.” I leave the connection with the preceding conversation as an exercise for the alert reader.

    OK… obviously having some fun here and I hope no one takes this either too seriously or too personally. The message is that someone has to pay for tech support and every imbecile hopes that they will be able to get free technical support for life at the expense of more responsible users. I don’t think anyone smart enough to be reading this blog falls into that category, but I do think that some of even these very smart people might fall into the logical mistake of not realizing that it is better to have faith in their own skills and to buy tech support as necessary, especially if that tech support is available for an absurdly low cost.

  23. James Fee says:

    Dimitri, the day I see you leave an one sentence response I’ll roll over and die. ;)

  24. Dimitri says:

    Ah, well, we couldn’t have that! A few more sentences, then, to err on the side of safety for James. :-)

    Somehow I neglected to correctly post a few lines on why Manifold’s interface is different. So here is a shortened version:

    Yes, Manifold’s interface is significantly different from classic GIS packages. This is inconvenient for users of classic GIS packages but wildly beneficial for the rest of the world. There are two main reasons for that:

    1. Other GIS packages, in particular ESRI’s, date from the 1990′s. This is such a long time ago that they were created at a time when there was no Internet, no widespread usage of cell phones, no DVDs, no Windows and people still actually used floppy disks with computers. Since then there have been many advances in both hardware and software technology. It would be astonishing if a new GIS package like Manifold failed to utilize more modern approaches than legacy packages, especially since those legacy packages are usually stuck with being backwards-compatible with methods dating to the early 90′s or before.

    2. Classic GIS packages were designed before the rise of mainstream Microsoft standards, and they are burdened with numerous vestiges of those non-Microsoft days. Manifold is deeply mainstream and Microsoft in nature, using things like the Windows “copy and paste” paradigm as central parts of the GUI. We do that to cater to the billions of people who think in terms of mainstream, Microsoft methods, even though we understand this is often alien to someone used to ESRI or MapInfo products.

    But, we feel that a smart GIS guy can always adapt to new methods (and is probably interested in learning about new approaches) while those billions of mainstream folks are not at all interested in learning opaque, non-Microsoft, ESRI ways of doing software.

    It never fails to amaze me how some ESRI guys don’t seem to realize a) just how alien arcstuff is to mainstream ways and b) no matter how big ESRI is in the very small pond of traditional GIS, it is essentially nonexistant in mainstream software markets.

    We are interested in proliferating GIS outside the small pond of traditional usage. We really believe there are tens of millions of mainstream users who can use GIS provided that it is a) affordable, b) as sophisticated as the other high-end applications they use and c) thoroughly devoted to supporting the Microsoft technologies they have chosen.

    To serve those billions of Microsoft users from which those tens of millions of new GIS users come, we have no choice but to design the package first and foremost to meet those three criteria. Making it similar to legacy packages is not one of those criteria and, in fact, strongly works against acceptance by the mainstream.

    For example, no one in their right minds thinks you can encourage mainstream sales by telling Microsoft people to code in “Avenue.” Better be an ActiveX or .NET language if you want to sell to mainstream Microsoft users!

    Some folks have suggested that Manifold cannot win the mass market if it does not first win in the small pond of legacy GIS, and that the only way to win in that small pond is to be an ESRI clone, to adopt ESRI nomenclature and ESRI methods. We strongly disagree. That’s a bit like saying that Dell could not have succeeded in the personal computer market if it did not first win in the minicomputer market by emulating a teletype paper punch terminal.

    OK, so maybe that analogy is making too much of a stretch to make the point. But it is still true that winning or losing a few tens of thousands of seats in legacy GIS (the legacy GIS market is so small that such small numbers make a difference) don’t really affect how you do in winning the mainstream. And if the price of winning that handful of seats in traditional GIS markets is that you lose the big prize in the mainstream, well, you can see how the strategy of being an ESRI clone is not so attractive.

    The bottom line is that there are plenty of experienced GIS people interested in new approaches, and those folks combined with a massive influx of new users with new ideas from mainstream markets make up a really active and progressive user community. It is those users who demand innovations upon which the future of GIS is based.

    That innovation is not going to come from products still stuck in 90′s ways of approaching GIS. Yes, it is comfortable to keep repeating the “same old, same old,” but it’s also boring and no way to make progress. So I’d advise all GIS professionals not to get stuck with the famous criticism, “His talents were equal to ESRI and he aspired no higher.” Keep reaching for new and better ways of doing GIS and you’ll be part of modern progress and not an obstacle to it.

  25. beerman says:

    For example, no one in their right minds thinks you can encourage mainstream sales by telling Microsoft people to code in “Avenue.”

    Can you saw “strawman”? You like to say how ESRI is stuck in the 90′s. Dimitri, please update your marketing research from the 1990′s. Avenue was part of a product that ESRI offered 10 years ago, in the 1990′s. It hasn’t been sold or really supported since the year 2000.

    Real GIS people laugh at you because your arguments are so dated. Why don’t you spend some time looking at the ESRI website and seeing amazing things like Model Builder, something you guys don’t have at all.

    Also, how would you feel if ESRI users compared their most recent product to Manifold 4.0? That is exactly what you are doing, and it is dishonest.

  26. Dimitri says:

    Fair enough: I grant that a citation to Avenue may be an overly shorthand way of citing ESRI’s attachment to ancient ways.

    In this respect I admit to being a bit lazy, as the more sophisticated “ESRI vs. Microsoft” discussion is much longer, because the issue in the last few years is not so much ESRI’s total unwillingness to do things Microsoft’s way as it is ESRI’s grudging acceptance of some Microsoft ways but only years too late. Simply poking at obviously dumb things is easier than making that more complex argument. But in all fairness a citation of Avenue is something that still affects very many ESRI users, quite likely more than use, say, VBA.

    Perhaps more current citations of ESRI not being with the Microsoft program would be the use of VBA instead of initially ActiveX and now .NET languages for scripting.

    Or, perhaps it would be better to consider the design of “geodatabases” as perpetuating obsolete shapefile notions encapsulated within Access .mdb, a DBMS format that Microsoft set out to end-of-life just before ESRI began using it.

    Access .mdb is flat out unreliable and dangerous as a storage methodology, especially when multiple users are working with the same data. A more modern choice would have been to use MSDE and then SQL Server Express. In fact, Microsoft itself is trying to “end of life” Jet (Access .mdb) by not even supporting it within 64-bit Windows.

    Model Builder is an interesting and in many ways an admirable thing, I grant you, but here also we see a desire to carve out something apart from the mainstream as opposed to recycling a mainstream notion. It’s directly analogous to people who sell SQL query contruction tools instead of supporting the use of vendor-invariant SQL.

    The problem with SQL query builders is that people end up spending a lot of time learning the query builder when they could have spent the same amount of time to learn SQL itself. So they end up having expertise which is not portable outside a specific package. Had they spent the same amount of time to learn SQL their expertise would be portable to hundreds of different packages.

    At manifold we have strong faith in Microsoft programming tools. We believe that if you leverage the vast industry resources for teaching and supporting programming in standard Microsoft development environments, be they VBscript, Javascript (Jscript), VB.NET, C# or whatever, you can learn true skills that will be more important to you than simply usage within Manifold or Arc. That is one of the many benefits of using standard Microsoft development facilities.

    So sure, we could introduce something like Model Builder and that would no doubt make it easier for beginners to string together sequences of actions and it would even make them more dependent upon our software and less able to ever move from it. But it wouldn’t make them more productive in the long term, nor would it serve them as well beyond the rank beginner stage as making it possible for them to apply the rich repretoire of existing Microsoft development tools. Nor, would it encourage new work in clever ways that are easily moved about in the context of execution, exporting parts of your task to DBMS engines, server side processes, client side processes and the like. Nor does it easily lend itself to code management and collaborative work environments as widely exist for standard Microsoft tools.

    For that matter, Microsoft has its own ideas about how things like Model Builder should be done, and a vendor determined to leverage Microsoft will use Microsoft approaches, such as Windows Workflow, instead of their own, competitive model builder. Using the Microsoft approach makes it more likely that whatever you do will a) integrate well with other Microsoft development resources and b) be supported in the future.

    To take just one very contemporary example, if you are doing things in Model Builder you have cut yourself off from the benefits of 64-bit code. If you do things in standard Microsoft development environments, you immediately benefit from every Microsoft advance in such areas.

    Note that so far I’m not tooting Manifold’s horn, I am praising Microsoft and showing respect for the immense depth and reach of Microsoft tools.

    If manifold ever does something like Model Builder no doubt we’ll base it on Windows Workflow Foundation or other horizontal Microsoft technologies. It won’t be any more “Manifold” than is the ability we give you to script in C# or VB.NET – it will be a Microsoft thing.

  27. GISDev says:

    OK Dimitri, you are in this over your head.

    “Perhaps more current citations of ESRI not being with the Microsoft program would be the use of VBA instead of initially ActiveX and now .NET languages for scripting.”

    Microsoft applications do allow VBA scripting even today. To claim VBA support is “not being with the Microsoft program” is disingenuous. VBA is still an integral part of Microsoft’s scripting platform. Claiming otherwise is a sign you don’t know what you are talking about re: scripting and the Microsoft platform.

    I’m curious how one uses “ActiveX” for scripting so please let me in to that one as ActiveX is really just OLE/COM (which ArcGIS supports). ESRI also supports .NET with ArcGIS, but as a .NET dev I can’t understand why someone would ever want to script with .NET.

    The “correct way” to script is to use a real scripting language such as Perl, Python, or Ruby. It just so happens that ESRI does support Python as a scripting language. Scripting with C# or VB.NET seems like using a sledgehammer when all a hammer is needed.

  28. PHL says:

    Scripting with ActiveX? I agree, WTF are you talking about there Dimitri?

    I’ll be the first to admit VBA sucks and I hate it with a passion, but VBA is Microsoft.

  29. DevMonkey says:

    “At manifold we have strong faith in Microsoft programming tools. We believe that if you leverage the vast industry resources for teaching and supporting programming in standard Microsoft development environments, be they VBscript, Javascript (Jscript), VB.NET, C# or whatever, you can learn true skills that will be more important to you than simply usage within Manifold or Arc. That is one of the many benefits of using standard Microsoft development facilities.”
    Oh like ESRI tools being built into Visual Studio? Gotcha.

    Seriously, no one in the GIS industry is tied more to Microsft than ESRI.

    http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=49635

    I don’t see an Manifold case study at all. rolleyes

  30. scourge says:

    “ActiveX languages” are languages exposed by “ActiveX scripting engines”, which is a fancy Microsoft term for a set of COM interfaces. Microsoft was using this to achieve a degree of language independency prior to .NET. There have been language engines coming from Microsoft (VBScript, JScript) and 3rd parties (Perl, Python, Tcl, etc). The technology is virtually everywhere with one of the biggest consumers being Internet Explorer.

    Dimitri has a point in that the ActiveX scripting engines are far more alive now than VBA.

  31. Leslie says:

    scourge, I don’t think so:

    Dimitri didn’t say ActiveX scripting he said ActiveX. ActiveX on its own can mean a lot of things to a lot of people. I’d never word it that way and while technically he might be right that you can do Active Scripting, he didn’t phrase it in that sense. I’m wagering he doesn’t really understand it, otherwise he’d use the correct terminology.

    I’ve never seen Manifold so I have no idea what Manifold used or uses for scripting. VBScript or JScript? ESRI uses both. I know at .NET 2.0, Active Scripting (which is what Dimitri should be saying instead of ActiveX) was depreciated.

    Now I’m a .NET guy so I’m happy with any product that allows me to use .NET and I see both Manifold and ESRI do so. The big kicker for me will be which one better implements IronPython. To me that is the key for scripting with .NET. Using C# (or even VB.NET) is overly complex for no good reason.

    So sure, we could introduce something like Model Builder and that would no doubt make it easier for beginners to string together sequences of actions and it would even make them more dependent upon our software and less able to ever move from it.

    Now that is insulting to me. I’ve been programming for 20+ years and I’ve used UML for years to model systems before I start programming. I feel the same should be allowed for GIS. If you don’t want people tied to your software, why not just use UML as it is the modeling standard? I’d rather be able to use my own favorite UML tool than have a GIS decide which one for me to use. Some might pick Visio, but give me Telelogic. Modeling isn’t a sign of beginner vs expert Dimitri. It never ceases to amaze me that people script in GIS and use their output as test cases, rather than model it first. Saves so much time.

    If manifold ever does something like Model Builder no doubt we’ll base it on Windows Workflow Foundation or other horizontal Microsoft technologies.

    Why bother? You seem to feel Manifold would be better served by not tying people to built in modelers. Just allow your users to use whatever they wish. You describe earlier that you don’t want to tie people to Manifold. Support for external modelers would be a way to get around that.

    a DBMS format that Microsoft set out to end-of-life just before ESRI began using it.

    I’m curious, where did you learn this. First I’ve heard that .mdb when end of life, let alone end of life before 2000. Provide me a link please.

    In fact, Microsoft itself is trying to “end of life” Jet (Access .mdb) by not even supporting it within 64-bit Windows.

    You have this a little wrong. Jet is already depreciated as far as Microsoft is concerned. The fact that it is not supported on 64-bit is a result of that. Of course Microsoft being Microsoft, they are still shipping Jet with Access 2007 (well they’ve tweaked JET so it isn’t the same as the distributed one anymore) so in a way Jet will still be around, just not available as part of MDAC.

    But this discusison brings us forward to what ESRI has done. They have begun the transformation from .mdb geodatabases to Microsoft SQL Server 2005 Express Edition which is the correct move according to Microsoft. Someone above had a nice Microsoft Case Study on the move.

    Access .mdb is flat out unreliable and dangerous as a storage methodology, especially when multiple users are working with the same data. A more modern choice would have been to use MSDE and then SQL Server Express.

    I disagree that back in 2000 ESRI could have ever used SQL Server Express because wasn’t around (“shipped” in 2005). MSDE 1.0 would have been available, but that was a disaster (I still have nightmares trying to use it). And ESRI has never allowed multiple users to edit a .MDB file so I’m not sure what you are after with that comment.

    But in all fairness a citation of Avenue is something that still affects very many ESRI users, quite likely more than use, say, VBA.

    More people use Avenue than VBA? Are you kidding me? Where the heck did you drag that up? At the UC I never hear anyone talk about Avenue anymore except over beers. VBA and VB are big topics at the UC.

    Perhaps more current citations of ESRI not being with the Microsoft program would be the use of VBA instead of initially ActiveX and now .NET languages for scripting.

    How the heck could ESRI use .NET in 2000 when it only shipped in 2002? And one could script using VBScript or JScript back in 2000, both are acceptable Active Scripting languages.

    Admin Note: I edited the time on this post -7 hours to reflect blog time change

  32. KoS says:

    Leslie and others…..don’t forget there are people who post here(which I have to remind myself at times). Who’s second language is english. Give them a benefit of a doubt if they don’t phrase it exactly.

    Heck, I was a high school prodigy. :lol And I stil don’t make sense at times the first time around.

    I don’t know enough about scripting or programming. I can do very basic or simple scripting in Avenue, amls, and python, for now.

    I’m more a “why” guy than a “how” guy anyway.

    So, I can’t comment on the specifics of what has been said. But I wanted to point out. If it doesn’t make sense or phrased right, doesn’t always mean someone doesn’t know their butt from a hole in the ground.

    KoS

  33. KoS says:

    Ok that is weird……my post should have shown up after Leslie’s. It’s before his?

    KoS

  34. James Fee says:

    Yikes, I screwed up. I noticed that my blog was set to UTC time, not Mountain Standard Time. I changed the clock and I guess it didn’t resolve all the older posts. I’m going to edit Leslie’s to fit better into the thread.

  35. PHL says:

    Dimitri seems to spout Microsoft specifics. To claim ActiveX on its own is a scripting language is incorrect.

    If he had said scripting with VB/JScript and ActiveX, then I would have been fine with that. I don’t think it is language that is getting in the way, it is Dimitri’s marketing speak.

  36. Dimitri says:

    “technically he might be right that you can do Active Scripting, he didn’t phrase it in that sense. I’m wagering he doesn’t really understand it, otherwise he’d use the correct terminology.”

    OK, you lose the wager. :-) Read back in the thread and you’ll see I wrote:

    “instead of initially ActiveX and now .NET languages for scripting.” …obviously using both “ActiveX” and “.NET” as modifiers for the word “languages.” This is short hand for “instead of initially ActiveX languages and now .NET languages for scripting.”

    I think it flows better in the construction I used, in particular employing an attractive alliteration between the initial “a” of “ActiveX” and “and” followed by a pleasantly resonant alliteration between the initial “n” of “now” and the nearby “n” of “dot Net.” Note that if I had injected an unnecessary extra “languages” into the sentence then the alliteration would have been lessened and the flow of the prose weakened.

    Such constructions are often used in English, unless, of course, one is writing for the barely literate or for folks who are new to the language. I apologize to those for whom English is not a first language and will do my best to use simpler language so as not to confuse those who are challenged by literary forms.

    After all, the last thing I’d want to do would be to allow someone’s inability to follow language to launch an imbecile-level discussion of semantic nits as opposed to a discussion of the heart of the matter. I mean, really, what is more important, that Manifold uses a wide array of contemporary Microsoft languages while ESRI does not, or that someone in this thread is more interested in doing a parsing backflip to avoid talking about exactly how far behind ESRI is in supporting Microsoft initiatives?

    So let’s talk about meat:

    It’s well known exactly what sort of scripting languages Manifold supports. See the discussion in

    http://www.manifold.net/doc/7x/scripts.htm

    which begins with…

    “Scripts are Manifold programs written in an ActiveX or .NET programming language that is installed on the computer system.”

    [An aside to the barely literate: Note that this first line uses an English construction similar to that which I used in my posting; however, it may be easier to parse because it has an "an" in front of the word "ActiveX," a requirement given the slightly different grammar employed in the sentence, but nonetheless employing the same shorthand technique I used.]

    The topic then goes on to show examples of scripting the usual “Hello World” example within Manifold using C#, JScript, JScript .NET, VB.NET, VBScript, PythonScript and PerlScript. Iron Python of course could also be used and that would be a fun addition to that topic.

    I trust everyone interested in writing code understands the richness of the Manifold approach compared to the ESRI model and that from a historical perspective also understands this path was open to ESRI at the same time it was open to Manifold.

    I think it would be instructive to go through the years and trace how ESRI seems to have adopted Microsoft ways only years after truly fanatic Microsoft supporters have done so and then in the end they’ve often gotten it wrong. ESRI’s use of VBA and .mdb are good examples that are 0bvious to most, so I happened to use them. They are at once examples of delay and simultaneously examples of getting it wrong.

    VBA is a particularly good example of that, as only someone who doesn’t understand Microsoft development environments would choose to utilize VBA within their application instead of doing what Manifold does, supporting first ActiveX and then .NET languages when .NET came to town. For a discussion of why VBA is a poorer choice, see

    http://www.manifold.net/doc/7x/programming_manifold.htm

    Frankly, if it is true that VBA and VB are the talk of the UC, that is very embarrassing for the UC. But, I suppose it is a step above Avenue and if folks want to strut around the UC acting as if writing code in VBA is somehow either sensible or contemporary there is no harm in allowing them their false conceits.

    It is of course commendable that those people writing in this thread with actual experience in the matter understand that using .mdb is utterly stupid. Well done. But if the defensive comment is that “well, they are moving to SQL Server Express 2005,” then I would respectfully point out that we are entering the year 2007 and so this is a fair example of my thesis, a typically long overdue move. There’s no reason it could not have been done long ago with MSDE, which long has been recognized as a much more reliable technology than .mdb.

    Regards to all,

    Dimitri

  37. Leslie says:

    I think it flows better in the construction I used, in particular employing an attractive alliteration between the initial “a” of “ActiveX” and “and” followed by a pleasantly resonant alliteration between the initial “n” of “now” and the nearby “n” of “dot Net.” Note that if I had injected an unnecessary extra “languages” into the sentence then the alliteration would have been lessened and the flow of the prose weakened.

    Again ActiveX scripting languages is incorrect. JScript is a language that can use ActiveX, but isn’t tied to it (nor VBScript). By the very nature of you sentence you fog the truth.

    Such constructions are often used in English, unless, of course, one is writing for the barely literate or for folks who are new to the language. I apologize to those for whom English is not a first language and will do my best to use simpler language so as not to confuse those who are challenged by literary forms.

    Sentence structure isn’t important in technology as much as getting the actual terms correct.

    After all, the last thing I’d want to do would be to allow someone’s inability to follow language to launch an imbecile-level discussion of semantic nits as opposed to a discussion of the heart of the matter. I mean, really, what is more important, that Manifold uses a wide array of contemporary Microsoft languages while ESRI does not, or that someone in this thread is more interested in doing a parsing backflip to avoid talking about exactly how far behind ESRI is in supporting Microsoft initiatives?

    What “Microsoft language” does Manifold use that ESRI does not? I’m not sure what you are going after here.

    “Scripts are Manifold programs written in an ActiveX or .NET programming language that is installed on the computer system.”

    [An aside to the barely literate: Note that this first line uses an English construction similar to that which I used in my posting; however, it may be easier to parse because it has an “an” in front of the word “ActiveX,” a requirement given the slightly different grammar employed in the sentence, but nonetheless employing the same shorthand technique I used.]

    Poorly written documentation is no excuse. You cannot not write ActiveX scripts, but you can write Active Scripting scripts.

    The topic then goes on to show examples of scripting the usual “Hello World” example within Manifold using C#, JScript, JScript .NET, VB.NET, VBScript, PythonScript and PerlScript. Iron Python of course could also be used and that would be a fun addition to that topic.

    All of which one can use with ESRI. What is your point?

    I trust everyone interested in writing code understands the richness of the Manifold approach compared to the ESRI model and that from a historical perspective also understands this path was open to ESRI at the same time it was open to Manifold.

    What happened in 2000 is irrelevant to the product today that supports all these “rich features”.

    I think it would be instructive to go through the years and trace how ESRI seems to have adopted Microsoft ways only years after truly fanatic Microsoft supporters have done so and then in the end they’ve often gotten it wrong. ESRI’s use of VBA and .mdb are good examples that are 0bvious to most, so I happened to use them. They are at once examples of delay and simultaneously examples of getting it wrong.

    I’m still not buying that example. ESRI made those choices in 1998/2000. When better solutions became available they offered them.

    VBA is a particularly good example of that, as only someone who doesn’t understand Microsoft development environments would choose to utilize VBA within their application instead of doing what Manifold does, supporting first ActiveX and then .NET languages when .NET came to town.

    But they have also always offered VBScript and JScript. ESRI gave people choice which you seem to say is good. Why is it only good for Manifold to give users options?

    For a discussion of why VBA is a poorer choice, see

    http://www.manifold.net/doc/7x/programming_manifold.htm

    Um you have got to be kidding me? That is documentation?

    Frankly, if it is true that VBA and VB are the talk of the UC, that is very embarrassing for the UC. But, I suppose it is a step above Avenue and if folks want to strut around the UC acting as if writing code in VBA is somehow either sensible or contemporary there is no harm in allowing them their false conceits.

    Of course you insult users. Why is it bad if users wish to use VBA or even VB6? It is their choice and insulting them just makes Manifold look bad. They were discussing it because ESRI only offered Python classes at the UC and people were wondering if both would still be supported. Get down off your high horse and stop insulting people.

    It is of course commendable that those people writing in this thread with actual experience in the matter understand that using .mdb is utterly stupid. Well done. But if the defensive comment is that “well, they are moving to SQL Server Express 2005,” then I would respectfully point out that we are entering the year 2007 and so this is a fair example of my thesis, a typically long overdue move. There’s no reason it could not have been done long ago with MSDE, which long has been recognized as a much more reliable technology than .mdb.

    You didn’t show me where .mdb has gone “end of life”. Please I ask again show me where that happened.

  38. James Fee says:

    Leslie and Dimitri, both your posts got thrown into comment moderation, and I deleted Leslie’s by mistake. I copied and pasted what he said (from the email that gets sent to me) and posted it under his name. Leslie, sorry about that and please review it and let me know if I copied it correctly.

    Lets drop the whole ActiveX vs Active Scripting argument here. I wouldn’t call them ActiveX scripts either, but I do know people use the term. I think Microsoft would prefer Active Scripting, but lets not get dragged into the gutter here. Not too many people are using either VBScript or JScript with current GIS platforms so this argument is irrelevant.

  39. scourge says:

    If I may…

    I believe Dimitri’s point with regard to scripting languages was that back then when both ESRI and Manifold could go either with VBA or with ActiveX scripting with languages such as VBScript, JScript and soon Perl, Python and others, ESRI has chosen to go with VBA while Manifold has chosen to go with VBScript and others, and that Manifold’s choice has turned out to be better than ESRI’s. Perhaps it is my ignorance but it seemed to me that ESRI did not allow using VBScript / JScript / Perl / Python back in 2000-2002. Manifold did.

    As regards Jet, it has been deprecated long ago. Here is a paper from 2002 (January), and I believe I have seen Microsoft papers with similar wording at least a year earlier:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/data_mdacroadmap.asp

    By extension, if Jet is deprecated, .mdb files are deprecated, too. I mean, if the only way to create / access .mdb files is said not to be in active development anymore (and is also said to be unsuitable for high-stress, high-concurrency or high-availability applications, and is also said not to have a 64-bit future – this, too, has been said back in 2002 and maybe even earlier), it is not very wise to choose the .mdb format as a means to store your data, right?

    Now, one could start a discussion on whether being “deprecated” means being “end-of-lifed”, but I surely have better things to do than participate in that.

  40. treo says:

    I am not a user of Manifold (yet?), but having had my own share of problems with .mdb files, I remember being less than happy with ESRI’s choice of .mdb as a base format for personal databases. From what I heard during the past three or four years, I believe I am in a good company. The decision to go with .mdb was just as dumb back then as it would have been today.

    My .02$.

  41. Leslie says:

    I believe Dimitri’s point with regard to scripting languages was that back then when both ESRI and Manifold could go either with VBA or with ActiveX scripting with languages such as VBScript, JScript and soon Perl, Python and others, ESRI has chosen to go with VBA while Manifold has chosen to go with VBScript and others, and that Manifold’s choice has turned out to be better than ESRI’s. Perhaps it is my ignorance but it seemed to me that ESRI did not allow using VBScript / JScript / Perl / Python back in 2000-2002. Manifold did.

    You would be incorrect. ESRI has offered VB/JScript as an option since ArcGIS 8 came out. That would be before 2000.

    As regards Jet, it has been deprecated long ago. Here is a paper from 2002 (January), and I believe I have seen Microsoft papers with similar wording at least a year earlier:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/data_mdacroadmap.asp

    By extension, if Jet is deprecated, .mdb files are deprecated, too. I mean, if the only way to create / access .mdb files is said not to be in active development anymore (and is also said to be unsuitable for high-stress, high-concurrency or high-availability applications, and is also said not to have a 64-bit future – this, too, has been said back in 2002 and maybe even earlier), it is not very wise to choose the .mdb format as a means to store your data, right?

    As I said, JET has been depreciated, I have no argument with that. BUT, technically JET has only been depreciated out of the MDAC as it is still used in Access 2007 (which just arrived). Of course you don’t get that version of JET without Access 2007 so I’ll go with the arguement that JET has been depreciated. That said going by your argument, by extension of Access still being offered, MDB has not been depreciated, nor is it end of life as long as MS Access is still being offered.

    Now you are right, no one in their right mind would use Personal Geodatabases going forward in 2007. That is why ESRI released the File Geodatabase and Personal SDE (which uses SQL Server Express) to allow users to migrate off of Personal Geodatabases. In fact ESRI over and over again at the UC told users to move beyond Personal Geodatabases and their limitations.

    Now, one could start a discussion on whether being “deprecated” means being “end-of-lifed”, but I surely have better things to do than participate in that.

    The only argument I have is the one where Dimitri says .MDB has been “end-of-lifed” which is incorrect as well as his assertion that ESRI didn’t offer “ActiveX” or as Microsoft developers say “Active” Scripting. They did and have so for many years. Yes they did offer VBA and by Dimitri’s argument of giving users choice, I think that was a good one. ESRI offers the latest Microsoft scripting choices so I’m not really sure what he’s arguing here.

    Should ESRI remove VBA from their product? Probably as soon as users are no longer using it. I would hope ESRI has been selling .NET to them, but as I try and stay away from VBA I dont’ know if they have been doing that. Honestly I can’t imagine any VBA programmer not looking at .NET these days especially since Microsoft now has IDE’s for .NET that are essentially free.

  42. scourge says:

    > ESRI has offered VB/JScript as an option
    > since ArcGIS 8 came out.

    Again, please forgive my ignorance but could you elaborate on that a bit? Do you mean by the above that since ESRI had a COM object model, one could use VBScript / JScript to drive it? Or do you mean that ESRI actually supported ActiveX scripting interfaces and allowed running scripts written in VBScript / JScript from within the main user interface? And did syntax highlighting? And allowed running scripts in Perl / Python? And supported the debugging interfaces? And supported using the above languages in the context of a web request processed by a web server (I heard that the object model of ArcIMS is completely different from that of other Arc products but that’s beside the point; if ArcIMS could run a script written in PerlScript that would satisfy the question)?

    If all that was there was a COM object model, that would not be much of an “offering”, certainly nothing that would qualify for “support for ActiveX scripting” by Manifold standards.

  43. scourge says:

    Sorry for not merging this into my first post…

    The use of the .mdb format by Access is very different from the availability of a supported interface for accessing .mdb files that would be in active ongoing development. Saying that .mdb is a viable long-term choice for storing tabular data since Access still uses it is akin to saying that .pcx is a viable long-term choice for storing images since many new graphic editors include a .pcx filter. This does not make sense.

    There have been numerous signs from Microsoft that Jet is going away at least the way we knew it. It has been said numerous times that one should not use Jet unless there is absolutely no way around it (eg, you already have an .mdb file which you have to read). Some folks listened and some didn’t. That’s it.

  44. Leslie says:

    Again, please forgive my ignorance but could you elaborate on that a bit? Do you mean by the above that since ESRI had a COM object model, one could use VBScript / JScript to drive it? Or do you mean that ESRI actually supported ActiveX scripting interfaces and allowed running scripts written in VBScript / JScript from within the main user interface?

    I mean that ArcGIS allowed and allows running of Active Scripts from the main user interface.

    And did syntax highlighting?

    No, but…

    And allowed running scripts in Perl / Python?

    Since ArcGIS 9

    And supported the debugging interfaces?

    Yes

    And supported using the above languages in the context of a web request processed by a web server (I heard that the object model of ArcIMS is completely different from that of other Arc products but that’s beside the point; if ArcIMS could run a script written in PerlScript that would satisfy the question)?

    ArcIMS is very different than ArcGIS Server so you couldn’t run anything that you wrote with ArcGIS Desktop and have an ArcIMS site handle it. If you did use ArcGIS Server, then you can do what you are asking. ArcIMS is on its way out with most ArcGIS Server being the method of choice since it is so well integrated into ArcGIS Desktop (poor choice of words on my part, but…)

    If all that was there was a COM object model, that would not be much of an “offering”, certainly nothing that would qualify for “support for ActiveX scripting” by Manifold standards.

    You can use the COM object model, but to sum up; ArcGIS has had Active Scripting since it came out. You don’t need to use the COM object model and you script from right inside the main interface (or write your script outside and run it from inside ArcGIS).

  45. Leslie says:

    The use of the .mdb format by Access is very different from the availability of a supported interface for accessing .mdb files that would be in active ongoing development. Saying that .mdb is a viable long-term choice for storing tabular data since Access still uses it is akin to saying that .pcx is a viable long-term choice for storing images since many new graphic editors include a .pcx filter. This does not make sense.

    I never said .MDB was a viable choice. I just pointed out that Dimitri was incorrect in saying that .MDB was end of life which it clearly isn’t. If he had just left it at JET is depreciated out of MDAC then he would have been fine, but he went futher calling .MDB end-of-life.

    There have been numerous signs from Microsoft that Jet is going away at least the way we knew it. It has been said numerous times that one should not use Jet unless there is absolutely no way around it (eg, you already have an .mdb file which you have to read). Some folks listened and some didn’t. That’s it.

    JET was depreciated out of MDAC at the same time ESRI offered new database solutions. I’m not sure what you are going at here. I can’t speak for ESRI, but I’m sure there were painfully aware of the JET issue and when the time came to move on, they were ready. Dimitri was spouting off Marketing slogans and he was incorrect on the main points as usual. He’s best off worrying about Manifold and not what ESRI has done or is doing. They have been at the cutting edge of Microsoft technology and have been recognized by Microsoft for it.

  46. [...] Just as gene therapy has been identified as having potential benefits, maybe the geospatial community should consciously enroll into meme therapy.  I think James Fee’s exploration of Manifold serves as a good example of this. [...]

  47. scourge says:

    I am sorry, Leslie, but I disagree. Of course, it is clear from Dimitri’s words that he is a marketing type, but I believe that his main points are indeed correct.

    Dimitri brought up an issue of ActiveX scripting, which is: once upon a time one could go with ActiveX scripting or with VBA; ESRI and Manifold have gone different ways and Manifold way turned out to be better. I believe this is a valid issue. OK, since you say that ESRI allowed using VBScript and JScript, it looks like ESRI actually tried to go both ways, but given that they did not allow using other ActiveX scripting languages until ArcGIS 9 (2004) and did not have other features that I mentioned (eg, did not even have the same object model for scripts running in the desktop UI and in the context of a web request until ArcGIS Server, which came in 2005), it still seems that ESRI did not go as far with ActiveX scripting languages as it could have gone, or as Manifold have gone. I don’t think it would be too much of a stretch to say that the decision to support VBA played a role, by at least constraining the resources available for supporting ActiveX scripting. Actually, you are the first guy to say to me that ArcGIS (8, right?) could debug VBScript / JScript – any chance you could point me to a tutorial discussing that or a screenshot of the ArcGIS environment doing that? I trust you, there is no question about it, but we might use a different definition of the word “debugging”.

    Dimitri brought up an issue of .mdb files, which is: once upon a time one could go with .mdb files or with other means to save data; ESRI and Manifold have gone different ways and Manifold way turned out to be better. Again, I believe this is a valid issue. There were plenty of suggestions and hints from Microsoft that Jet is going to be deprecated before it was actually deprecated, meaning back then when there was that choice that I am describing. The fact that ESRI has added support for other databases after going with .mdb has little to do with the initial choice of .mdb being bad. Nor did later ESRI’s efforts to move their customers from .mdb to something else seem to be particularly effective. Just ask how many people are still using .mdb files today. It will take ages to get agencies like this to switch to another format:

    http://nhd.usgs.gov/data.html

    The way I see it, Dimitri’s main thrust is correct. ESRI have made plenty of bad choices in the past.

    In fact, I would strengthen this. Not only ESRI have made plenty of bad choices in the past but they continue making one bad choice after another today. Just look at what they are doing with Oracle Spatial. Then compare that to Manifold.

  48. mfuser says:

    ArcIMS is very different than ArcGIS Server so you couldn’t run anything that you wrote with ArcGIS Desktop and have an ArcIMS site handle it. If you did use ArcGIS Server, then you can do what you are asking

    And yet another issue bolstering Dimitri’s comments. ArcIMS was a separate product, totally divorced from ArcGIS. It was a great way to sell another $10,000+ product, however.

    But, very, very bad architectural choice. With Manifold, the GIS and IMS are the SAME product. So, if you wrote a script or SQL query in the desktop GIS, it was immediately available for use in the IMS portion. This was great design, and great foresight.

    ESRI on the other hand offered one band-aid after another. First it was ArcIMS, then ArcIMS allow a .mxd to write out an AXL file. Again, just a band-aid. Nothing you really did in ArcGIS could be used in the IMS product. The object model wasn’t even the same. The reality is, there appeared to be absolutely no communication between the IMS and desktop guys.

    Now when I hear about AGS, I just shake my head and have to wonder if it really lives up to the hype.

    For years ESRI has fought off their bad moves by using marketing money to hype a product that really was junk:

    (c. 1988 – MapInfo has a PC product – ESRI markets PC ARC/INFO (LOL!)

    (c. 1993 – Intergraph MGE on NT – ESRI ports ARC/INFO workstation to NT (LOLouder)

    (c. 1995 – Smallworld, Intergraph, and just about everyone else uses COM – ESRI puts VB wrappers around AMLs and calls it ODE (LOL so hard I’m now crying..)

    (c. 1998 – AutoDesk puts out an IMS product – ESRI puts out ArcView IMS

    In each of these cases, ESRI was able to stave off competition by marketing the hell out of a bad architectural idea. ESRI users bought up the hype, rather than trying something else.

    Dimitri is correct. Manifold has consistently made good architectural decisions, and ESRI has not. At the moment, ESRI may have some advantages to Manifold, but when I try to look out 5 years from now, I see ESRI dead in the water. The fact that they can’t run in true 64-bit mode, or have the ease of integration with things like Oracle tells me they will not be able to spin the boat around fast enough. I seriously doubt that ESRI has the ability to take full advantage of quad processors. Manifold has that ability, due to some decisions they made early on about their architecture. ESRI is just too wedded to their older product line, using file based systems.

  49. mfuser says:

    Oh, I should have mentioned something on the .mdb. I would not say that back in 1998 when ESRI was probably designing the geodatabase that choosing Access was a bad idea. Who knew, right?

    What was bad however was the actual design of the geodatabase. Do you see how many tables are requried to make a geodatabase work? Its mind boggling. There are probably 20 interrelated tables. What I find bad about that is that it forces users, if they want to work with geodatabases, to use an ESRI product. The geodatabase design is so cumbersome, that they have made the move to “own the technology stack”. How in the world can someone develop a 3rd party application using a geodatabase, with some kind of ESRI product to make sense of all the tables. With Manifold, the allow geometry storage into any database. So, if you can read SHP, WKB, or WKT, you can develop an application. ESRI’s geodatabase would make this impossible.

    It is very similar to the ArcIMS templates. I can’t tell you how many people have said that it is virtually impossible to make fundamental changes to the templates because again, there are around 20 different HTML tables integrated together. Most people (at least those with the skills) just re-write their own. Others, have to get a consultant. I think ESRI realized that there was greater potential to make money in the consulting field than software sales, as their product is priced too high.

  50. Dimitri says:

    Well, never one to evade opening up yet another can of worms, a few small comments in continuation…

    First, I agree with James that this ActiveX thing is getting circular in splitting hairs. My point was intended to be that ESRI is late to the party with detailed Microsoft support as Microsoft fanatics would like and that in most cases their support is not only late but not as deep as Manifold (syntax highlighting, to name just one point). So I give up on that and agree to shift away from that.

    I agree that .NET is a more contemporary topic. In that vein, I’d be curious to know if ESRI’s ArcGIS suite (and, which products exactly in that suite are required) enables you to write a script in C# or other .NET language.

    For example, in any Manifold edition from Personal at $245 on up you can open a scripting window, write a script using C# (such as the “Hello, World!” example) complete with syntax highlighting and run it. You get useful extras such as a nice “references” dialog, the ability to compile to a .dll and so on. Not bad considering that this same $245 entry level edition also includes all sorts of other wonderful things that you’ld have to buy extra ESRI products, such as ArcEditor, etc.

    For that matter, from $295 on up you also get IMS built-into Manifold and from $395 on up you also get OCI to enable direct use of Oracle Spatial, whether as part of Spatial or just using the “Locator” capability built into every Oracle distribution, including the free Express versions. No need for any “SDE” addition.

    Anyway, the point of this is that by having contemporary scripting tightly integrated into every Manifold edition from the simplest on up with nothing extra to buy you make it possible for people to do things like “test drive” application ideas within Manifold with a C# script, using identically the same object model, in a simple, informal way before they commit to coding, say, a web application using IMS.

    I could be wrong about this and look forward to being corrected if that is the case, but as far as I know you can’t do that with ESRI products. They appear to neither have the same degree of built-in support for .NET scripting within the common user interface that is always available to you, nor is the object model the same within disparate products, such as ArcInfo or ArcIMS.

    When scripting in .NET languages like C# within the actual GIS desktop itself, I respectfully advance the proposition that the details count. Having that richly enabled within the GIS desktop without the need to buy extras (not even Microsoft extras), having all the details worked out within GUI and the object model to enable practical usage (such as the ability to either execute on the fly or compile to a .dll), and having all details of that object model worked out so that there is no change when important associated capabilities such as IMS or Oracle Spatial are brought into play, well those are all key details that go into being truly supportive of such Microsoft technologies in a way that ESRI does not match.

    But it is indisputable that competition from Manifold is pushing ESRI to be more Microsoft than they used to be. If you follow the trail of Manifold innovations and then take a look at the laundry list of new things in their 9.x series you can see a lot of things that popped up in ESRI products that a few years earlier appeared in Manifold. That competition is good for ESRI users.

    The discussion with Oracle Spatial is also illuminating. You can see the different mindset between ESRI and Manifold by considering the differences in how ESRI and Manifold approach storing spatial data on Oracle, where Manifold uses data types provided by Oracle and ESRI tries to reinvent the wheel. If this is not an example of a technical blunder on ESRI’s side and a sound technical decision on Manifold’s side, I do not know what is.

    For the technical side of this, see:

    1. A thread on Oracle forums with Oracle people bringing up numerous reasons for SDO_GEOMETRY and a number of people suggesting that ESRI has minimal support for Oracle SDO format – no way “full support” claimed by ESRI:

    http://forums.oracle.com/forums/thread.jspa?messageID=777192&#777192

    1. A letter in Directions Magazine by Simon Greener, who responds to comments by an ESRI proponent and shreds ESRI to pieces on this same issue:

    http://www.directionsmag.com/letters.php?letter_id=203

    1. A post on Paul Ramsey’s blog which criticizes ESRI for choosing to reinvent the wheel once again, this time for PostgreSQL:

    http://geotips.blogspot.com/2006/12/postgis-for-sde.html

    All three of the above pieces come from independent sources, not from any manifold.net person.

    In all fairness to ESRI, what is a technical blunder in the way ESRI interacts with Oracle Spatial is not really a blunder from their business viewpoint because their objective is to trap you within an ESRI product family silo.

    This is the same theme from shapefiles on: ESRI seems to design their products not so much for GIS optimality as to trap you into having no choice but to use ESRI products. Start with shapefiles and use of .dbf (go dBase II! ), next, after shapefiles became commodities (.dbf or not), ESRI rolls out “geodatabases,” which seem to have little merit other than trying to capture you within an .mdb-ized form of shapefiles unique to ESRI, and now there comes a new trap in the form of Personal SDE, I guess intended as a ramp for volunteers to stick their heads into ESRI’s bear trap in a smooth, scalable way to end up being trapped within ArcSDE.

    I acknowledge that people will disagree with this opinion, but it seems to me that it is a much better thing to acknowlege the primacy of RDBMS choice both for individuals and organziations and not let the GIS attempt to trap your general DBMS data into a GIS vendor silo. If you want to store geometry in a DBMS, Manifold will certainly let you do that but our recommendation is to use either the DBMS vendor’s native spatial data types or some “open” data type like OGC WKB. In either case you are not trapped within the GIS vendor’s own silo. Oh, and while it is true that to get Oracle Spatial capability with Manifold you have to buy Enterprise Edition at $395, the straight storage of geometry using OGC WKB or other methods in DBMS like .mdb, SQL Server Express or pretty much any other DBMS (MySQL, etc) is built into every Manifold edition, even Personal at $245. No need to buy some special “SDE” personal or otherwise.

    In closing, one thing that is too amusing to let pass:

    “[ESRI] have been at the cutting edge of Microsoft technology and have been recognized by Microsoft for it.”

    You mean, like failing to support Vista when the rest of the world, including Manifold, does? Visit the ESRI knowledge base and here is what it says about support for Vista:

    “ArcGIS 9

    ESRI is working to certify its ArcGIS 9 software for Microsoft Vista based on the final Windows Vista release. In general ESRI does not certify its software for products that have not been released for final, which would include the beta and release candidate versions of Microsoft Windows Vista. ESRI will provide more information on our Windows Vista support as we complete our testing with the final version of Vista. We anticipate fully supporting Windows Vista.

    ArcView 3.3 and Windows Vista

    ArcView 3.3 is in mature support and as such ESRI does not certify ArcView 3.3 on new operating systems. ESRI has not tested it and do not have plans to do so. “

    Not to beat an old horse to death, but this is about the same way ESRI fails to support 64-bit Windows and multicore processors.

    It’s true that from time to time Microsoft does feature ESRI support for new Windows initiatives. But they do that in the spirit of showing that even a known slacker like ESRI can get it up to support this or that Windows feature. They don’t need to do it for well-known Microsoft extremists like Manifold, who are expected from the earliest inkling of a new Microsoft initiative to be supporting it.

    Let me close with trying to relate this tail end of a thread to the beginning: at every turn Manifold will do things as much as possible to recycle Microsoft ways of doing things and to bring in good ideas from a wider base of users. That often leads to doing things in a different way than ESRI does. I suggest that is a good thing, even from the perspective of someone who never intends to switch from ESRI, because unless you start doing things in a different way than ESRI does you never force ESRI to catch up to where the mainstream is going. Seeing a different approach in Manifold gives you ammunition to use as an electric cattle prod on ESRI to get them to catch up.

    And, if you look at the most contemporary things happening in the mainstream, “catch up” to Manifold is exactly the right phrase. Right now, ESRI lags on Vista, on 64-bit Windows, on multi-core processor usage and on leveraging the native power of mainstream “spatial” DBMS like Oracle Spatial. As you get into details, you’ll see many more examples in things like a unified object model, the fine details of support for .NET scripting and the like. As this business heats up and vendors, like the DBMS folks, Internet people and tools vendors reach more into GIS, I say that the ESRI lag effect will increase.

    For example, I don’t think any serious person would suggest that Oracle will drop Spatial to use either Personal SDE or ArcSDE, it’s obviously not the direction the open source DBMS’s are headed and anyone guessing what Microsoft might do in this area would have to ask themselves if Microsoft are the sort of weak-minded technologists who would turn over control of their DBMS market to ESRI by adopting something like ArcSDE as a standard.

    Ask yourself those questions and I respectfully suggest that you are most likely to conclude that the DBMS vendors are going to do what’s right for them, will welcome GIS packages that seamlessly interoperate with the DBMS vendor’s native technology and that ArcSDE will increasingly be the odd man out.

  51. Pete says:

    MFUser: It seems you draw too many conclusions based on the wrong data.
    1988 : PCs are starting to be a big thing : ESRI markets PC ARC/INFO (LOL!)
    1993: Windows NT is getting popular: ESRI ports ARC/INFO workstation to NT (LOLouder)

    1998 – The Internet gets really polular: ESRI puts out ArcView IMS

  52. mfuser says:

    Pete,

    nice spin. but you don’t get the point. In each of those examples, most would say that ESRI made the wrong technology choice. So sure, they knew they had to get into the game, but when they did, they did it in a bad way. Case in point: ESRI technical staff admit that ArcView IMS was their first attempt at doing something like that, and they were learning along the way.

    I could go on-and-on, like how ESRI is now trying to roll all those things like ArcToolbox back into the ArcGIS Desktop because they see the busted apart product as a bad move. And, they are backing off of ArcIMS to more towards AGS. They know that ArcIMS was not a good architecture.

  53. Leslie says:

    Dimitri brought up an issue of ActiveX scripting, which is: once upon a time one could go with ActiveX scripting or with VBA; ESRI and Manifold have gone different ways and Manifold way turned out to be better.

    How did the Manifold way turn out better? They went the same way except ESRI supported VBA for some weird reason. Both went .NET, both went Perl/Python/etc. I fail to see how ESRI giving users the choice of VBA (no matter how I hate that development environment). Dimitri has said that the choice of Manifold is to give their users as many Microsoft choices as possible. ESRI just did them one better.

    I believe this is a valid issue. OK, since you say that ESRI allowed using VBScript and JScript, it looks like ESRI actually tried to go both ways, but given that they did not allow using other ActiveX scripting languages until ArcGIS 9 (2004) and did not have other features that I mentioned (eg, did not even have the same object model for scripts running in the desktop UI and in the context of a web request until ArcGIS Server, which came in 2005), it still seems that ESRI did not go as far with ActiveX scripting languages as it could have gone, or as Manifold have gone. I don’t think it would be too much of a stretch to say that the decision to support VBA played a role, by at least constraining the resources available for supporting ActiveX scripting.

    I agree with everything except that VBA constrained them. I’ve talked with the Geoprocessing guys and they have never looked at VBA as a choice. If it was anything that kept ESRI from moving forward with Perl/Python it was AML.

    Actually, you are the first guy to say to me that ArcGIS (8, right?) could debug VBScript / JScript – any chance you could point me to a tutorial discussing that or a screenshot of the ArcGIS environment doing that?

    I’m not sure about Manifold, but ESRI has a dumb policy of not allowing two versions of the software to run at the same time, so ever though I have ArcGIS 8 disks around (though I think only 8.3 at this point), I won’t bother with screen shots. Just go to ESRI support site and search for VBScript and ArcGIS 8, I’m sure something with turn up.

    I trust you, there is no question about it, but we might use a different definition of the word “debugging”.

    It sounds at least to me that Manifold took the scripting one step further than ESRI did which I commend them. My ONLY issue with this Active Scripting is that Dimitri keeps saying ESRI only supported VBA which they didn’t.

    Dimitri brought up an issue of .mdb files, which is: once upon a time one could go with .mdb files or with other means to save data; ESRI and Manifold have gone different ways and Manifold way turned out to be better. Again, I believe this is a valid issue. There were plenty of suggestions and hints from Microsoft that Jet is going to be deprecated *before* it was actually deprecated, meaning *back then* when there was that choice that I am describing. The fact that ESRI has added support for other databases *after* going with .mdb has little to do with the initial choice of .mdb being bad. Nor did later ESRI’s efforts to move their customers from .mdb to something else seem to be particularly effective. Just ask how many people are still using .mdb files today. It will take ages to get agencies like this to switch to another format:

    http://nhd.usgs.gov/data.html

    I don’t argue with anything you say there other than ESRI didn’t realize that JET was going away. They have had options available ready to go when JET was depreciated. It has never been much of an issue for many people because of SDE.

    The way I see it, Dimitri’s main thrust is correct. ESRI have made plenty of bad choices in the past.

    Why does Dimitri care? Honestly I don’t mind people being critical of ESRI (I’m a loud one in my office), but he needs to get the facts correct before jumping on the “ESRI Sucks” bandwagon. I can think of hundreds of other things wrong with ArcGIS than its scripting support.

    In fact, I would strengthen this. Not only ESRI have made plenty of bad choices in the past but they continue making one bad choice after another today. Just look at what they are doing with Oracle Spatial. Then compare that to Manifold.

    Don’t get me started with Oracle Spatial. I used to be an Oracle DBA and while 10g is much better than previous versions, it never had the power of SDE (though it is more open than SDE so I can understand why people don’t like SDE). ArcGIS 9.2 and Oracle Spatial are like two peas in a pod these days though, but I’d not use it. Give me SQL Server 2005 and SDE and I’m happy.

  54. Leslie says:

    And yet another issue bolstering Dimitri’s comments. ArcIMS was a separate product, totally divorced from ArcGIS. It was a great way to sell another $10,000+ product, however.

    ArcIMS predates ArcGIS, it was never divorced. That said it is “only” $6,000 and not worth even 1/10th that. Dimitri should stick with the ArcGIS Desktop/Server combo which costs an arm and a leg and he should have no problem with his cost argument. No ESRI user even thinks of ArcIMS as an ArcGIS application.

    But, very, very bad architectural choice. With Manifold, the GIS and IMS are the SAME product. So, if you wrote a script or SQL query in the desktop GIS, it was immediately available for use in the IMS portion. This was great design, and great foresight.

    At the time in the mid 90′s there was no ArcGIS product so I’m not how you’d program for a platform that doesn’t exist. As I’ve said over and over again, all you have to use is ArcGIS Server and you can do whatever you wish on both Desktop and Server.

    ESRI on the other hand offered one band-aid after another. First it was ArcIMS, then ArcIMS allow a .mxd to write out an AXL file.

    Actually that isn’t how it worked. ArcIMS read AXL files, you needed ArcMap server to server up MXDs.

    Again, just a band-aid. Nothing you really did in ArcGIS could be used in the IMS product.

    Again I’ll say it again, ArcGIS Server has been that product. ArcIMS and ArcGIS are two totally different products.

    The object model wasn’t even the same. The reality is, there appeared to be absolutely no communication between the IMS and desktop guys.

    Again, there is total communication between the ArcGIS Desktop and Server guys. The ArcIMS “guys” don’t existing anymore. They have been folding into the Server team and are just keeping ArcIMS alive for those who want it. At 9.2, ArcIMS is pretty much being left behind (though I’d say at 9.0 that happened). There will be no enhancements to the product other than making sure it continues to work with ESRI products. Jack even compared it to ArcInfo Workstation. It will still be shipped, but there won’t be any real work done on it.

    Now when I hear about AGS, I just shake my head and have to wonder if it really lives up to the hype.

    The hype from the UC was it was slow and buggy. Does that live up to the hype? Seriously there is a ArcGIS Server blog up (Check Planet Geospatial) if you want to see some demos.

    For years ESRI has fought off their bad moves by using marketing money to hype a product that really was junk:

    (c. 1988 – MapInfo has a PC product – ESRI markets PC ARC/INFO (LOL!)

    (c. 1993 – Intergraph MGE on NT – ESRI ports ARC/INFO workstation to NT (LOLouder)

    Um, ArcView was out.

    (c. 1995 – Smallworld, Intergraph, and just about everyone else uses COM – ESRI puts VB wrappers around AMLs and calls it ODE (LOL so hard I’m now crying..)

    Don’t forget MapObjects….

    (c. 1998 – AutoDesk puts out an IMS product – ESRI puts out ArcView IMS

    Oh the early versions of ArcIMS were crap, but at the time real IMS guys were using MapObjects IMS.

    In each of these cases, ESRI was able to stave off competition by marketing the hell out of a bad architectural idea.

    Actually I agree with this statement 100%. ESRI is where they are because they are marketing better.

    ESRI users bought up the hype, rather than trying something else.

    ESRI users buying the hype? Most of use have had it thrust upon them. ;)

    Dimitri is correct. Manifold has consistently made good architectural decisions, and ESRI has not.

    If Dimitri left it at that I’d have no problem, but he keeps throwing out statements not built on fact (Like .MDB has gone end-of-life).

    At the moment, ESRI may have some advantages to Manifold, but when I try to look out 5 years from now, I see ESRI dead in the water.

    Nope, in fact they will just keep getting bigger. ESRI is entrenched like Microsoft with government agencies (including mine). No way anyone including Autodesk get that kind of traction. The only way that this could be an issue would be on the server side and that is going to be a Google/Microsoft thing.

    The fact that they can’t run in true 64-bit mode

    In 5 years that will be a huge issue, but for now it isn’t.

    or have the ease of integration with things like Oracle tells me they will not be able to spin the boat around fast enough.

    Huh? I’ve used ArcGIS and Oracle for years. Of all the issues I’ve ever seen with Oracle and ESRI it has been someone screwed up their Oracle install.

    I seriously doubt that ESRI has the ability to take full advantage of quad processors.

    You’d be wrong.

    Manifold has that ability, due to some decisions they made early on about their architecture. ESRI is just too wedded to their older product line, using file based systems.

    Huh? What file based system are you talking about? ArcSDE? cough

  55. mfuser says:

    Um, ArcView was out.

    I loved ArcView, but please, you cannot say that ArcView, especially during those mid 1990′s years was doing great geoprocessing. No topology, etc.. And, everyone was still using ArcInfo workstation to edit data.

    Also, it was an application that ran in Windows, but was nothing even close to a Windows product. No copy/paste between applications like Word or Excel, very limited right-mouse stuff, Avenue, which while it was cool, was unnecessary. Again, go back to Dimitri’s original premise. When ESRI had an opportunity to roll out a Windows based product, they produced ArcView. MO was much closer. But, even you have to admit MO was never really followed up on by ESRI. It was in response to the need to have something COM at the time, but was just dreadfully limited.

    Don’t forget MapObjects….

    MO was cool, but severely limited. Very few objects in the object model, no on-the-fly projections, etc. It certainly was great for “put a map in your app”, and I used it for that, but it really was woefully limited in its functionality.

    So, don’t get me wrong. MO wasn’t junk. It was a very nice COM application, but basically, ESRI stopped at around 30-40 objects. They should have had the full ESRI tool suite associated with it.

    Oh the early versions of ArcIMS were crap, but at the time real IMS guys were using MapObjects IMS.

    I’ll give you that. It was a much better solution. I don’t know why they didn’t exploit that more.

    At the time in the mid 90’s there was no ArcGIS product so I’m not how you’d program for a platform that doesn’t exist.

    its called product planning :-) Everyone knows that at that time, there was a real disconnect at ESRI between the product group and the consulting group. This should have been forseen. Again, it just validates alot of what Dimitri has said. ESRI goes like gangbusters in some direction, perhaps without thought of the future implications.

    You made lots of references to AGS. What if back in the mid 90′s, when they were planning for ArcGIS and ArcIMS someone said, hey, lets integrate these. But, that didn’t happen. What happened was a bunch of guys developed ArcIMS in a box, and gave no thought of how it would integrate with other ESRI products. They have literally been playing catch-up ever since to make the product useable.

    In 5 years that will be a huge issue, but for now it isn’t.

    I don’t think so. Especially when we can start taking advantage of 64-bit with enormous datasets. Manifold isn’t there yet either, but in a year I think they will be, and they should be able to make small work of terrabyte size data.

    ESRI users buying the hype? Most of use have had it thrust upon them.

    LOL!

    Huh? What file based system are you talking about? ArcSDE? cough

    I’m thinking about coverages, grids, and shapefiles. Yes, they are moving more towards databases (geodatabase?), but so much of the product is based around those other formats. I think that has a huge effect on how they move the product further.

    Their biggest mistake may have been not killing their first-born (ARC/INFO). They let it hang around too long. But, ArcView was certainly not the solution, so, I suppose ARC/INFO and coverages were necessary until they could get something like ArcGIS out. But even then, they settled on personal geodatabases which we’ve already talked about.

  56. Leslie says:

    First, I agree with James that this ActiveX thing is getting circular in splitting hairs. My point was intended to be that ESRI is late to the party with detailed Microsoft support as Microsoft fanatics would like and that in most cases their support is not only late but not as deep as Manifold (syntax highlighting, to name just one point). So I give up on that and agree to shift away from that.

    If late to the party you mean 1999, then sure. Syntax highlighting is nice, but I’ll take IntelliSense in ArcGIS 9.x over it anyday.

    I agree that .NET is a more contemporary topic. In that vein, I’d be curious to know if ESRI’s ArcGIS suite (and, which products exactly in that suite are required) enables you to write a script in C# or other .NET language.

    Yes and no, I’m getting the feeling that Manifold handles this a different way. I can script with C#, but not in the same way you call it. ESRI pushes their uses to Python for this now, which would play into your “giving users choices” mantra. It isn’t an issue for me as I’d choose Python, but I’ll give you this point.

    For example, in any Manifold edition from Personal at $245 on up you can open a scripting window, write a script using C# (such as the “Hello, World!” example) complete with syntax highlighting and run it. You get useful extras such as a nice “references” dialog, the ability to compile to a .dll and so on. Not bad considering that this same $245 entry level edition also includes all sorts of other wonderful things that you’d have to buy extra ESRI products, such as ArcEditor, etc.

    You’d be surprised how many times you’d need ArcInfo to acomplish a simple task. For me it is the Erase function. Why the heck is this not in ArcView? These kinds of arguments from the Manifold team do have traction with ESRI users, not VBA vs VBScript. ;)

    For that matter, from $295 on up you also get IMS built-into Manifold and from $395 on up you also get OCI to enable direct use of Oracle Spatial, whether as part of Spatial or just using the “Locator” capability built into every Oracle distribution, including the free Express versions. No need for any “SDE” addition.

    Again, Manifold has the cost done on ESRI, but you don’t need SDE to use Oracle.

    Anyway, the point of this is that by having contemporary scripting tightly integrated into every Manifold edition from the simplest on up with nothing extra to buy you make it possible for people to do things like “test drive”

    Cutting in here to say how about a test drive of the application for ESRI users. Just fax in the CD and you’ll give a 30-day code. Now that is a test drive I’d sign up for

    application ideas within Manifold with a C# script, using identically the same object model, in a simple, informal way before they commit to coding, say, a web application using IMS.

    ESRI does the same with Python and to a different extent with C#. Its kind of an apples and oranges thing here, but I understand your point.

    I could be wrong about this and look forward to being corrected if that is the case, but as far as I know you can’t do that with ESRI products. They appear to neither have the same degree of built-in support for .NET scripting within the common user interface that is *always* available to you, nor is the object model the same within disparate products, such as ArcInfo or ArcIMS.

    ArcIMS and ArcGIS are different platforms so yes you are correct there isn’t a common user interface. But users can use ArcGIS Desktop and Server so they’d be able to leverage the way you are talking about using those products. For most ArcGIS users, ArcIMS is irrelevant these days, but I’m sure it will be YEARS before we see them fall off the server world.

    When scripting in .NET languages like C# within the actual GIS desktop itself, I respectfully advance the proposition that the details count. Having that richly enabled within the GIS desktop without the need to buy extras (not even Microsoft extras), having all the details worked out within GUI and the object model to enable practical usage (such as the ability to either execute on the fly or compile to a .dll), and having all details of that object model worked out so that there is *no* change when important associated capabilities such as IMS or Oracle Spatial are brought into play, well those are all key details that go into being truly supportive of such Microsoft technologies in a way that ESRI does not match.

    I think ESRI is as supportive as any company, but lets just say we differ here. I talked to the Microsoft guys at the ESRI .NET SIG at the UC and they were pretty jazzed to see what ESRI was doing with their products. With ArcGIS Desktop and Server, you have access to what you are proposing.

    But it is indisputable that competition from Manifold is pushing ESRI to be more Microsoft than they used to be. If you follow the trail of Manifold innovations and then take a look at the laundry list of new things in their 9.x series you can see a lot of things that popped up in ESRI products that a few years earlier appeared in Manifold. That competition is good for ESRI users.

    Totally agree

    The discussion with Oracle Spatial is also illuminating. You can see the different mindset between ESRI and Manifold by considering the differences in how ESRI and Manifold approach storing spatial data on Oracle, where Manifold uses data types provided by Oracle and ESRI tries to reinvent the wheel. If this is not an example of a technical blunder on ESRI’s side and a sound technical decision on Manifold’s side, I do not know what is.

    I’m of the mindset Oracle Spatial is crap (having managed a system for years). I prefer the SDE method, but I won’t try and convince anyone of that. You choose the detabase storage method that works best for you. Most of the problems I’ve seen with Oracle and ESRI has been on the Oracle side (user error). I think this is because ESRI is very strict on how this stuff is stored so you lead yourself open to problems. I’ve deployed Oracle Spatial and ESRI in the past with success so it isn’t like it can’t be done. No surprise that ESRI favors SDE though.

    3. A post on Paul Ramsey’s blog which criticizes ESRI for choosing to reinvent the wheel once again, this time for PostgreSQL:

    http://geotips.blogspot.com/2006/12/postgis-for-sde.html

    I’ve followed PostgreSQL with great interest and can only hope that James banging on ESRI will result in a great PostgreSQL solution. I’m not hopeful.

    All three of the above pieces come from independent sources, not from any manifold.net person.

    And I thank you for that. ;)

    In all fairness to ESRI, what is a technical blunder in the way ESRI interacts with Oracle Spatial is not really a blunder from their business viewpoint because their objective is to trap you within an ESRI product family silo.

    Totally agree, they do as much as they can to allow you to connect, but in then end they don’t go far enough. BUT I’m an SDE lover so to each their own.
    This is the same theme from shapefiles on: ESRI seems to design their products not so much for GIS optimality as to trap you into having no choice but to use ESRI products. Start with shapefiles and use of .dbf (go dBase II! ),

    To be fair, Shapefiles are as close to an interchange format as we have. I hope to god something comes along that surplants it. GML?

    next, after shapefiles became commodities (.dbf or not), ESRI rolls out “geodatabases”, which seem to have little merit other than trying to capture you within an .mdb-ized form of shapefiles unique to ESRI,

    Technically you mean Personal Geodatabases because SDE is a Geodatabase also. They rolled out ArcSDE at the same time so we had robust choices back then (at a cost I’ll give you that).

    and now there comes a new trap in the form of Personal SDE, I guess intended as a ramp for volunteers to stick their heads into ESRI’s bear trap in a smooth, scalable way to end up being trapped within ArcSDE.

    It is free with ArcGIS so it isn’t like you are trapped. And there is the new file geodatabase. I think most users prefer to have the well integrated ArcSDE than Oracle, probably due to ESRI not supporting other databases well, but it is well done. (from ESRI’s standpoint) There are ways to get “unlocked” from SDE using open source solutions.

    I acknowledge that people will disagree with this opinion, but it seems to me that it is a much better thing to acknowlege the primacy of RDBMS choice both for individuals and organziations and not let the GIS attempt to trap your general DBMS data into a GIS vendor silo. If you want to store geometry in a DBMS, Manifold will certainly let you do that but our recommendation is to use either the DBMS vendor’s native spatial data types or some “open” data type like OGC WKB. In either case you are not trapped within the GIS vendor’s own silo. Oh, and while it is true that to get Oracle Spatial capability with Manifold you have to buy Enterprise Edition at $395, the straight storage of geometry using OGC WKB or other methods in DBMS like .mdb, SQL Server Express or pretty much any other DBMS (MySQL, etc) is built into every Manifold edition, even Personal at $245. No need to buy some special “SDE” personal or otherwise.

    I don’t disagree with anything you are saying there. I disagreed with the point that you said ESRI didn’t support VBScript and MDB was end-of-life.
    In closing, one thing that is too amusing to let pass:

    “[ESRI] have been at the cutting edge of Microsoft technology and have been recognized by Microsoft for it.”

    You mean, like failing to support Vista when the rest of the world, including Manifold, does? Visit the ESRI knowledge base and here is what it says about support for Vista:

    ԁrcGIS 9

    ESRI is working to certify its ArcGIS 9 software for Microsoft Vista based on the final Windows Vista release. In general ESRI does not certify its software for products that have not been released for final, which would include the beta and release candidate versions of Microsoft Windows Vista. ESRI will provide more information on our Windows Vista support as we complete our testing with the final version of Vista. We anticipate fully supporting Windows Vista.

    It runs on Vista. But James pointed out on his blog how ESRI released ArcGIS 9.2 the day before Vista arrived so they didn’t have to support it. It runs fine as far as I can tell.

    ArcView 3.3 and Windows Vista

    ArcView 3.3 is in mature support and as such ESRI does not certify ArcView 3.3 on new operating systems. ESRI has not tested it and do not have plans to do so.

    Come now, ArcView 3.3. It is in Mature Support which means “ESRI will not provide any further Patches and hot fixes for products that have reached the Mature Support phase. New environments will not be certified for Mature Support phase.”. If Vista kills off ArcView 3.x I’ll be very happy.

    Not to beat an old horse to death, but this is about the same way ESRI fails to support 64-bit Windows and multicore processors.

    Not an issue for me on the desktop or server for fiscal year 2007, but I do understand for some this is a huge deal.

    It’s true that from time to time Microsoft does feature ESRI support for new Windows initiatives. But they do that in the spirit of showing that even a known slacker like ESRI can get it up to support this or that Windows feature. They don’t need to do it for well-known Microsoft extremists like Manifold, who are expected from the earliest inkling of a new Microsoft initiative to be supporting it.

    OK?

    Let me close with trying to relate this tail end of a thread to the beginning: at every turn Manifold will do things as much as possible to recycle Microsoft ways of doing things and to bring in good ideas from a wider base of users. That often leads to doing things in a different way than ESRI does. I suggest that is a good thing, even from the perspective of someone who never intends to switch from ESRI, because unless you start doing things in a different way than ESRI does you never force ESRI to catch up to where the mainstream is going. Seeing a different approach in Manifold gives you ammunition to use as an electric cattle prod on ESRI to get them to catch up.

    I can’t argue with any of that.

    And, if you look at the most contemporary things happening in the mainstream, “catch up” to Manifold is exactly the right phrase. Right now, ESRI lags on Vista, on 64-bit Windows, on multi-core processor usage and on leveraging the native power of mainstream “Spatial” DBMS like Oracle Spatial. As you get into details, you’ll see many more examples in things like a unified object model, the fine details of support for .NET scripting and the like. As this business heats up and vendors, like the DBMS folks, Internet people and tools vendors reach more into GIS, I say that the ESRI lag effect will increase.

    I hope this is marketing speak because I hope the software engineering side of Manifold isn’t assuming that ESRI won’t offer products that could leapfrog the competition. Ask James what he knows about ArcGIS 10 and you’ll come away with some great ideas for Manifold.

    For example, I don’t think any serious person would suggest that Oracle will drop Spatial to use either Personal SDE or ArcSDE, it’s obviously not the direction the open source DBMS’s are headed and anyone guessing what Microsoft might do in this area would have to ask themselves if Microsoft are the sort of weak-minded technologists who would turn over control of their DBMS market to ESRI by adopting something like ArcSDE as a standard.

    I’ve integrated ArcGIS with Oracle Spatial with great success. This hasn’t been an issue for me. Using SDE is not weakminded either. Insult the product, not the person using it and maybe people might listen to you more rather than tune you out.

    Ask yourself those questions and I respectfully suggest that you are most likely to conclude that the DBMS vendors are going to do what’s right for them, will welcome GIS packages that seamlessly interoperate with the DBMS vendor’s native technology and that ArcSDE will increasingly be the odd man out.

    Are you sure about that? I mean what does Oracle care as long as people are buying Oracle? I think the whole ESRI/Oracle spat has left Oracle the odd man out. How nice would it have been to see Personal SDE on both Oracle and Microsoft? Of course ESRI won’t try and help Oracle out given the history there.

  57. Leslie says:

    I loved ArcView, but please, you cannot say that ArcView, especially during those mid 1990′s years was doing great geoprocessing. No topology, etc.. And, everyone was still using ArcInfo workstation to edit data.

    True, but what product on the PC in 1990 could do what ArcView 2.1b could do? Sure geoprocessing was a pain in the ass back then (if you could even call it that), but it was ArcView 3.x that got GIS into the hands of “the common man” and out of the UNIX world it was in. Was it ESRI marketing that did that, no doubt, but we are here today because of it.

    Also, it was an application that ran in Windows, but was nothing even close to a Windows product. No copy/paste between applications like Word or Excel, very limited right-mouse stuff, Avenue, which while it was cool, was unnecessary.

    Remember what we were running in 1990? Windows 3.11 for Workgroups.

    Again, go back to Dimitri’s original premise. When ESRI had an opportunity to roll out a Windows based product, they produced ArcView.

    See above, your better argument is to say ESRI fumbled the time between 1990 and 1999 when ArcGIS arrived.

    MO was much closer. But, even you have to admit MO was never really followed up on by ESRI. It was in response to the need to have something COM at the time, but was just dreadfully limited.

    Actually you can still buy MO these days…

    MO was cool, but severely limited. Very few objects in the object model, no on-the-fly projections, etc. It certainly was great for “output a map in your applet”, and I used it for that, but it really was woefully limited in its functionality.

    So, don’t get me wrong. MO wasn’t junk. It was a very nice COM application, but basically, ESRI stopped at around 30-40 objects. They should have had the full ESRI tool suite associated with it.

    I think when it arrived the thought would be that it would go further, but with ArcGIS and its object model ESRI never put anymore effort in it. Those bastards!

    I’ll give you that. It was a much better solution. I don’t know why they didn’t exploit that more.

    Well MOIMS couldn’t run on a server as a Service, it was just an application that ran. So you’d have to log into windows on reboot to make sure MOIMS was running. We tired many times to get it to run as a service, but it wasn’t pretty.

    its called product planning :-) Everyone knows that at that time, there was a real disconnect at ESRI between the product group and the consulting group. This should have been forseen. Again, it just validates alot of what Dimitri has said. ESRI goes like gangbusters in some direction, perhaps without thought of the future implications.

    ArcIMS has been a stopgap between nothing and ArcGIS Server. So if that validates what Dimitri’s been saying so be it. Pre-Windows NT I’m not sure how you’d program for something that would run on an operating system that was 3 years down the road and still release it today.

    You made lots of references to AGS. What if back in the mid 90′s, when they were planning for ArcGIS and ArcIMS someone said, hey, lets integrate these. But, that didn’t happen. What happened was a bunch of guys developed ArcIMS in a box, and gave no thought of how it would integrate with other ESRI products. They have literally been playing catch-up ever since to make the product useable.

    No argument there, ESRI will be an also ran in the web server market as will Manifold. This space will default to Microsoft/Google in the future. Mark my words.

    I don’t think so. Especially when we can start taking advantage of 64-bit with enormous datasets. Manifold isn’t there yet either, but in a year I think they will be, and they should be able to make small work of terrabyte size data.

    Fair enough. As I said I can’t really argue for or against 64-bit support.

    I’m thinking about coverages, grids, and shapefiles. Yes, they are moving more towards databases (geodatabase?), but so much of the product is based around those other formats. I think that has a huge effect on how they move the product further

    Now coverages and grids date from the 1980′s, Shapefiles from the early 1990′s and Personal Geodatabases from the late 1990′s. I don’t think support for coverages is holding them back.

    Their biggest mistake may have been not killing their first-born (ARC/INFO).

    How does workstation keep ESRI from inovating. They haven’t added a feature in 10 years. They just keep it up and running so old farts like me can run our AML scripts.

    They let it hang around too long. But, ArcView was certainly not the solution, so, I suppose ARC/INFO and coverages were necessary until they could get something like ArcGIS out. But even then, they settled on personal geodatabases which we’ve already talked about.

    Coverages were the format that ArcInfo uses. ArcView could never edit them so that is why shapefiles became the standard. It took many years to get users to start using geodatabases (SDE, Personal) and stop thinking about shapefiles. The format choice that users make is their own choice. It would be one thing if ESRI locked you into these formats, but they don’t.

  58. James Fee says:

    Boy what a difference a week makes. I’ve been out all day and this thread didn’t fall into the name calling disaster that other threads have. Good job guys. :)

  59. mms says:

    Not to mention that as the thread goes on, both arguing sides are coming closer and closer to each other to see that the number of things that they agree on is much higher than the number of things they disagree on. :-)

    mfuser: Manifold has consistently made good architectural decisions, and ESRI has not.

    Leslie: If Dimitri left it at that I’d have no problem, …

    All tongue in cheek aside, you are right James, this is a big refresher from the past flames. I happen to completely disagree with Leslie on the Oracle / SDE thing, but the tone of this thread makes me comfortable saying “to each his own”.

    May this trend of having civilized discussions continue in the new year! Belated Merry Christmas and slightly early Happy New Year to all!

  60. Pete says:

    Just want to add, that Shapefiles is not the bad thing you all make it. Yeah it has a bunch of limitations, but with a proper spatial index, it can actually give you exceptionally read performance, compared to any spatial databases, as long as your query-filters are spatial only. This makes them very efficient for rendering in an IMS (whether it is ESRI software or any other IMS). And as someone else pointed out, it is as good as a defacto standard for exchanging spatial data, even though it is now at least 10 years old.

  61. mfuser says:

    May this trend of having civilized discussions continue in the new year! Belated Merry Christmas and slightly early Happy New Year to all!

    well, I think you have Leslie to thank for that. Leslie has been a very good sparring partner, while at the same time respectful in tone.

  62. Bill Dollins says:

    I agree with the observation about shapefiles being an interchange format. They are not pretty but non one ever asks me for anything else when I’m trying to send them data. Where GML is concerned, I am never asked about it. If it’s not a shapefile, then someone is asking about KML. The market may leave OGC behind here.

    This is a very good discussion. I am well acquainted with the ESRI side of the discussion and the Manifold side is helping me learn a little more about that. But it’s the implicit discussion of issues relating to technology and data that I find most refreshing.

    Much better that the recent flame wars.

  63. Christopher says:

    This whole 64-bit issue isn’t that big for most people, but support for multiple core processors is. I want a GIS platfrom that takes advantage of multiple core processors.

  64. Bob C says:

    [blockquote]This whole 64-bit issue isn’t that big for most people, but support for multiple core processors is. I want a GIS platfrom that takes advantage of multiple core processors.[/blockquote]

    I don’t know about that.. I keep hitting VM limits with my larger raster collections (about 1.5 GB) even if ‘actual’ memory usage is in the half a gig range. 64-bit gives a heck of a lot more flexibility in that regard.

  65. Dimitri says:

    64-bit is an easy way to get an immediate performance boost: it’s unsubtle, but highly effective – simply install x64 Windows and then plenty of cheap RAM, say 8GB or more.

    Even if you don’t have a lot of RAM the better memory management in 64-bit Windows helps. Here are some numbers taken from recent measurements of topology overlays comparing the original 7x release with the new generation of faster algorithms that have been released as “technology previews” and which will likely be finally out in one of the free 7x updates within a week:

    Some performance figures for the original release of 7x (org: 32-bit / 64-bit) vs this build (new: 32-bit / 64-bit):

    test 1 (clip intersect) – org 641 sec / 497 sec – new 15 sec / 11 sec – speedup 44x

    test 2 (clip subtract) – org 655 sec / 513 sec – new 25 sec / 21 sec – speedup 25x

    test 3 (union) – org 1252 sec / 1053 sec – new 18 sec / 17 sec – speedup 66x

    test 4 (split) – org 1196 sec / 425 sec – new 34 sec / 28 sec – speedup 25x

    We will have more numbers later on published on the Manifold forum, but the above should give a general idea. The speedup factors are in tens and 64-bit code is consistently faster than 32-bit code (take a look at test 4 where 64-bit code outperforms 32-bit code by a factor of 2.5 – thanks to more efficient memory management!). This is so even though those test machines did not have a lot of RAM in them (I think they were only in the 2GB to 4GB range).

    It is true that using multiple cores effectively is the way of the future, with common use of dual core processors now and a new wave of quad core processors about to become common in 2007.

    But parallel processing on multiple cores is very difficult to do well even if you have had the foresight to design the architecture of your system to support it. Manifold got started doing massively parallel algorithms (see the founding legend at http://www.manifold.net/doc/7x/about_manifold_system.htm ) so it is something we’ve always tried to keep in mind (it was one of the reasons to do topology on the fly, for example).

    Anyway, 2007 is shaping up to be an interesting year in both the 64-bit arena and the multicore arena. RAM continues to get cheaper, 64-bit processors are expected even by pre-teens for their home computers and by mid 2007 there will be plenty of motherboards with two sockets for quad-core processors, for a total of eight cores, at a cost factor where the average professional operator would consider that for a personal desktop system. I want one already! :-)

  66. DaveB says:

    I, like many of you, use many different pieces of software to get my job done, and each has its own merits and weaknesses, Manifold included. I am definately NOT an ESRI “fan-boy” — I do also use ESRI software, but I’d be among the first to fault their many design flaws. So, having hopefully set myself up as relatively impartial…

    The one thing that always rubs me the wrong way about Manifold’s marketing strategy is the “holier than thou” mentality they display, along the lines of “because we do it the Microsoft way, we’re doing it the Right way” and “where Microsoft leads, there goes Manifold, thus we are cutting edge.”.

    That’s all fine, well and good — provided that you believe that Microsoft never makes mistakes and always has the best design available. Unfortunately history does not entirely support that belief.

    Indeed, Microsoft adopts and abandons technologies almost as rapidly as ESRI is faulted for in arguments above. And duct-tape fixes existing products to keep up with the times, much as ESRI is also faulted for above. (what were Win 95/98/ME if not stop-gap fixes for the 16- to 32-bit transition?) Or implements short-sighted solutions only to be replaced by later redesigns (WinG vs DirectX comes to mind, or really, any of their “media” -related initiatives). Or the gradual borrowing of Mac GUI over the last few releases 95/98/ME/2K/XP, is that true innovation? Or consider that we saw a fully OO o/s with NEXTSTEP in 1989, and MS is still playing catch-up with those concepts. So, perhaps it would be wise for Manifold to watch where it throws stones.

    Facetiously: Did Manifold ever release a version for Microsoft Bob?

    One specific example is Manifold’s use of the standard color dialog versus the AV3′s color palette, that comparison is part of their published marketing. Granted, AV3′s color palette is absolutely atrocious, but that’s also the only reason why Microsoft’s dialog wins that comparison – as almost ANY other color dialog would have been better!

    “Standard” doesn’t always mean “better”, in fact it’s often just the lowest common denominator. Just go ask Photoshop users what they think of the MS color dialog. There’s nothing wrong with a non-standard solution if it is custom tailored to the domain of a specific problem. The Manifold manifesto would ask you to believe otherwise.

    As for cutting-edge: go check out the dialog used to install fonts with Windows XP — that’s still a leftover from the Windows 3.1 days! Again, just to point out that “being in bed with Microsoft” doesn’t necessarily guarantee innovation.

    Those, and other readily available similar examples, suggest to me that Manifold’s Windows-centric marketing message is a bit over-the-top.

    Don’t get me wrong, I do commend Manifold for being cutting edge and rapidly implementing modern technologies — it’s only their posturing and marketing of such that carries it a bit too far for my personal taste.

  67. Dimitri says:

    “The one thing that always rubs me the wrong way about Manifold’s marketing strategy is the “holier than thou” mentality they display, along the lines of “because we do it the Microsoft way, we’re doing it the Right way” and “where Microsoft leads, there goes Manifold, thus we are cutting edge.”.

    That’s all fine, well and good — provided that you believe that Microsoft never makes mistakes and always has the best design available. Unfortunately history does not entirely support that belief.”

    Well, it’s good to know where you stand and it is admirable for you to state your anti-Microsoft feelings. You’re entitled to those, and it is an act of ethics to speak openly about the matter so that those people who prefer their vendors to be heart and soul supportive of their decision to leverage the Microsoft ecosystem will know you do not share their interests.

    I praise your integrity – it is so much more refreshing than those anti-Microsoft zealots who accept Windows work but grumble the entire time about how the world is a bunch of retards for not recognizing the superiority of NEXT or Linux or whatever.

    I also appreciate that you have contributed yet more material to search engines so that anyone seeking fanatic support for Microsoft in GIS can discover one more testimonial to Manifold’s no-holds-barred support for Microsoft. Our support for Microsoft is a competitive distinction that we would like to preserve against the inevitable cheats, you know, companies that don’t really support Microsoft enthusiastically but try to give the impression that they do so as not to lose any business. So every testimonial that we are pro-Microsoft fanatics is good.

    That’s the bottom line for us: if 96% of the world’s computing users, representing billions of people, choose Microsoft, that’s good enough for us. We’re not going to adopt a “holier than thou” attitude and suggest they are retards for choosing Microsoft. No way. We will commend them on their choice, the practicality of gaining immense economies of scale and the merits of having the world’s largest software ecosystem at their beck and call. And then we will do all in our power to assure our products leverage that choice of Microsoft as much as possible.

    If anyone has a problem with that or is offended by it, that’s OK by me. Just please make sure to post as often as you can in as many threads as you can about how those darn folks at Manifold are annoyingly supporting Microsoft in such an enthusiastic and fanatic way. Please spare no effort to make sure that everyone knows that when it comes down to supporting Microsoft in GIS, Manifold is the way to go. That’ll learn ‘em! :-)

    In a related vein, I hope that for the benefit of the traditional GIS community people will avoid repeating the mistakes that led to the effective extinction of UNIX on the desktop. The key mistake was failing to listen to the interests of the mainstream, of putting elitism ahead of attention.

    GIS right now is a tiny minority, but those who play their cards right will help move GIS onto the mainstream as a much more widely dispersed class of horizontal applications. The path to mainstream share goes through the Microsoft ecosystem and the key objective is winning share in that ecosystem. You don’t win share in the Microsoft ecosystem by having effete arguments over what technical detail is better in NEXT or Be or Mac or Linux than in Windows: you win share in Microsoft ecosystems only through expert, informed, truly committed support to those ecosystems.

    There are tens of millions of new GIS users up for grabs, and it is in the interest of virtually all GIS professionals to see the traditional niche expanded into the bigtime. That means more deals for everyone, more work for consultants, more opportunities for business niches in vertical markets, more support for academics – the works.

    Them be the stakes, so let’s all keep our eye on the prize and try to move the conversation back to how to best leverage the Microsoft ecosystem for the benefit of all of us in GIS and on how to roll out the welcome carpet for all of those millions of Microsoft-oriented people who we know can benefit from the experience the GIS community has developed over the years.

    With wishes for a happy, prosperous and Microsoft-centric New Year to all,

    Dimitri

  68. Bill Wight says:

    It’s not Manifold’s support of Microsoft that makes it appealing to me, it’s the support for Oracle Locator and Spatial.

  69. Justin says:

    /i> why is everything in italics up above

  70. Dimitri says:

    Ah… forgot to mention: Just to show there is no “holier than thou” prejudice against ESRI ways of doing things when they represent a genuine advantage, yesterday manifold.net issued a free update to 7x which includes an optional add-in to do topology overlays using ESRI-style stored topology.

    See

    http://forum.manifold.net/Site/Thread.aspx?id=32803&ti=633029715499170000

    Note that the comments state that ESRI’s way of doing things is sometimes indeed faster than Manifold’s. Users are invited to see for themselves by making apples-to-apples comparisons with the new add-in using their own data. If someone prefers to use stored topology in Manifold they can now do so.

    As mentioned in the announcement, we think the merits of topology on the fly recommend it for most users even in cases where stored topology is faster. When parallelization takes greater hold in 2007 onward there will be even greater incentive to go the topology on the fly route.

    But, with the publication of this free tool if anyone disagrees with those opinions they can ignore them and use stored topology if that’s what they prefer.

  71. DaveB says:

    Dimitri, thank you for that massive marketing tirade offered as a response. I suspect you may have missed the point.

    In fact, you’re trying to sell me on something I’ve already bought into. Windows is the only O/S I use, by choice, and you already have my cold hard cash for Manifold.

    The key is that I find Microsoft worthy of support despite their flaws. Rose-colored glasses are strictly optional – their history should be as open to critical review as that of any other software developer.

    The goal was not to bash Microsoft, but to expose the inequity of your arguments.

    Specifically, my intent was to suggest that many of the prior arguments made against ESRI in this thread could just as easily have been made against Microsoft, and thus perhaps such arguments were not entirely fair.

    Or is it that we may excuse imperfection from Microsoft, but from no one else? Such an implication may be what reads as a “holier than thou” tone in your prior posts above. (and elsewhere, there is definately a pattern)

    I retain my prior opinion: Manifold itself is great, but its marketing bugs. I also disapprove of election year smear campaigns. I’d rather see you focus on the many positives the software has to offer than see any more of the “their product is old and stupid” sort of stuff. Sure, it’s true, their software IS old and stupid, but that doesn’t make the smear campaign any prettier.

    Still, best of luck with that approach, may it serve you well and bring continued and increasing success in the new year.

  72. Dimitri says:

    “Or is it that we may excuse imperfection from Microsoft, but from no one else? “

    I don’t see where you are going with this. The point that was under discussion was a complaint about Manifold’s emphatic support for Microsoft. We do that because Microsoft markets have billions of people to sell to, and those prospective customers want their vendors to fanatically support Microsoft. So we do that. Whether or not Microsoft has imperfections is not the point. Of course they do. So what?

    It’s a bit like if you are the seafood business and you want to catch billions of fish you go to the oceans (instead of to small ponds) because the oceans are where most of the fish are. Are there “imperfections” encountered when fishing in the oceans? Sure there are! – storms imperiling the noble fisherman, sharks biting off part of your catch, a desire not to ensnare one’s marine mammal kin, a desire to sustain fish populations to maintain everyone’s way of life and all that. But oceans are still where the fish are. Imperfections are just part of the vast ecosystem and environment.

    “I’d rather see you focus on the many positives the software has to offer than see any more of the “their product is old and stupid” sort of stuff.”

    It’s always nice to focus on the positives and you are certainly right that is a good approach. But, it is also never possible to please all people all of the time.

    In particular, more often than not in my experience when I have heard an experienced ESRI user complain about Manifold’s marketing if you ask them the detail about what they specifically dislike it ends up being that Manifold has said something perfectly true and on-point that makes ESRI look really bad and the ESRI person prefers that the matter not be raised at all.

    Sometimes it is also a side-effect of the strongly pro-Microsoft stance of Manifold’s marketing. I don’t know if that is the case here.

    You have to remember that our target market, people who have no qualms about their use of Microsoft, are really fed up with vendors who say they support Microsoft but in fact are slipshod about how they do so. Our fanatical focus on Microsoft with zero ego issues about Microsoft being the star of the show (so much in contrast with ESRI, which seeks central account control, even primacy, over Microsoft in joint accounts) is a competitive advantage that is very helpful to play up for those people seeking pro-Microsoft vendors.

    We’re not shy about letting people know that’s the case, and we have no intention of allowing ESRI to get away with what is a competitive weakness. It’s a bit like a firm engaged in organic food production that encounters another firm from the conventional market that seeks to gain organic food buyers in a “line extension” maneuver but really is not as deeply committed to true organic farming practises (you’d be amazed how much chemistry can be applied and still have the label “Organic” in many jurisdictions).

    It’s understandable that the corner-cutting firm would like everyone to be genteel and not so explicit about fanatic support for organic farming, but being genteel with a competitor not as committed to true organic farming is not only foolish from a competitive perspective for the true organic vendor, it is also doing a disservice to their customers, who probably really want to know if a vendor is heart and soul committed to organic farming.

    Likewise, the “their product is old and stupid” sort of stuff I would guess (you don’t give examples, so I have to guess) probably is exactly on point. It’s not a smear to tell people they are getting raped financially to buy an old-fashioned product. That’s simply telling the truth and letting the chips fall where they lie.

    It’s also a duty to help new users avoid wasting their time by getting surprised by legacy traps that experienced GIS practitioners know to avoid.

    The very many intelligent people who are now entering the GIS market from the Microsoft community at times find some legacy GIS technology and practises to be, literally, unbelievable. They think they’ve got to be missing something as surely no sensible person would be doing anything as titanically stupid as, say, use shapefiles to exchange projected data without bothering to note the coordinate systems used, right?

    It saves such newbies a lot of wasted time when they are told straight up, no, you’re not missing anything and yes, it really is that dumb but it’s still done anyway and here are ways to deal with that.

    I think some experienced GIS practitioners have become so accustomed to some of these things that they neither confused nor outraged by them. But that’s not the case with new GIS users who deserve to be put on notice about some particularly stupid things they will encounter to help save them time.

    As you point out, every ecosystem has its imperfections, and most would admit as thinking, experienced GIS people that (to take just one example of something that Manifold has famously called stupid) for all of their merits for their original intended purpose, some formats like shapefiles have been grossly misused to the deep misfortune of generations of GIS users, both experienced and newbies.

    As for outrage at Manifold’s marketing… well, we tell it like it is. As you point out, the competitor’s software is indeed “old and stupid” so I don’t see much gain from a competitiver perspective in being so genteel as to not mention that.

    If one of our competitors is raping people by selling them old stuff for 20 to 40 times more than is common practise in Microsoft markets, well, too bad. We’ll not be shy about mentioning that. If y0u think Manifold should be more genteel, my reaction is astonishment that you don’t have outrage at, say, ESRI, for raping people on price.

  73. Getting back to learning the user interface, if anyone has read this far.
    I basically taught myself from the helpfiles arcview 3.1, then arcview 8.1 then Manifold 6.

    I found Manifold by far the easiest to learn, although you do need to read the help file.
    I sometimes find it hard to look things up quickly or search in the help, but if you start from the contents and really read it, there is a huge amount of detail and useful examples, and even some bits that are good for a laugh.
    (like the bit on export problems that says the best solution is to convince the person you are exporting to, to buy manifold, even better if they are a large company with 1000s of licences. (it does offer more helpful answers too)).

    I can’t comment on the support. You get a couple of free support incidents with each licence, I have never used one because I have always gotten excellent free help from the Manifold forum.

    There are bits of the interface that could be improved, but generally its pretty good, I think the main problem people have is its different from what they are used to.

    Try comparing the workflow of adding a new layer/drawing and drawing a few area and line objects between manifold and arc, it is vastly easier in manifold.
    Far better than autocad or arc help files.

  74. Christopher says:

    Michael Dufty:

    I think many things in Manifold are easier than in ESRI, however, probably an equal number of easier in ESRI too. Its just the nature of the beast.

    I used the help files for a few days, but wasn’t really diligent in going through them. I then got the training videos. To be honest, I didn’t even work through the training, I just watched the videos and then got a sense of how things were done.

    I used the older videos which was actually a project to create a landcover map. That was really useful to see the Manifold workflow for creating a real project. I haven’t needed to get the newer videos, so I don’t know what they are like

  75. I got the videos after the stage where I really needed them, but still picked up some useful things.
    The newer videos are more comprehensive, I haven’t watched but sat in the same office while someone else watched them.

    I am now at the point where when I need to use an old arcmap file its easier to import and convert the whole thing to manifold than to try to remember how to use arc. But its quite possible that if I changed to arcmap and didn’t use manifold for 3 years the opposite would be true.

    I got a trial of mapinfo recently and tried to have a play with it and got absolutely nowhere until I managed to find a 3rd party online tutorial somewhere.

  76. Christopher says:

    I agree with your MapInfo experience. I do better when I can sit with someone and he shows me how to do something. Videos are a good way to have that experience.

    Do you know where you got the MapInfo videos? They would be cool to check out.

    Have you tried the programming videos? I did not know if they are obsolete now.

  77. Vasileios Vlastaras says:

    From my point of view a contemporary GUI should lead the user in doing things not the opposite. If the user has to learn the GUI then the war is already lost ! And here is where Manifold is poor. It doesn’t cost to have an efficient GUI these days. There are pleanty of nice GUI controls out there. All this approach of endless toolbar buttons with simmilar icons that make no sense is a joke. This is the 90s approach and it is dead. The Manifold GUI unfortunately needs a complete reengineering. As far as it concerns the compare of Manifold and ArcGIS I can say that I run a department of 12 people in the past and it took more or less 3 days for not experienced users to be able to perform most tasks needed in ArcGIS. This is completely impossible in Manifold. So yes, ESRI ‘s software costs a lot but Manifold software + time needed to perform tasks by not experienced users costs more !!!
    Personally if I have to perform simple tasks I will go for Open source products like uDig that can be used in just 5 minutes even by the most inexperienced users !
    I think that users should not read help files at all these days ! It is a waist of time and money for a company especially if they are going to leave the job soon and be replaced by others !

  78. Dimitri says:

    I have to admit the following staggered me:

    “I think that users should not read help files at all these days ! “

    I sincerely wish you the best of luck with that viewpoint, and just as sincerely hope you never buy another manifold.net product. :-) … there are some points where people of good faith must simply agree to disagree.

    I don’t know a single example of a sophisticated software package designed to accomplish sophisticated tasks that could be efficiently learned and utilized to remotely near its capabilities without reading documentation, at least not for 99% of humans.

    Perhaps the classic example is watching a beginner flail away at PhotoShop, just trying to draw a straight line. No doubt nearly everyone on this forum could come up with similar examples of indisputably world-class packages that require reading of documentation and some study to master: Visual Studio, Illustrator, whatever.

    One reason such packages have an initial learning curve is that GUIs which are totally self-documenting (such as certain Wizard GUIs) tend to be highly self-limiting and ultimately frustrating for users who are not abject beginners. Assuming your audience is a sophisticated bunch that will be using the package on a regular basis to do sophisticated things, you need to design your GUI to provide maximum efficiency and ease of use to the experienced user. That’s often quite a different GUI than one which is very easy to learn by a beginner and which automates simple tasks.

    I grant you there are some extraordinary geniuses who can get the hang of complex things astonishingly quickly. And there are some very patient people who like puzzles who will spend days and weeks puzzling out interfaces without reading documentation. But for most people, getting real value out of a sophisticated package in sophisticated settings requires reading help.

    This is just as true of Manifold products as it is of ESRI products. I just do not believe that the average beginner new to GIS can sit down and do anything sophisticated with ArcGIS without reading documentation. In fact, anecdotal evidence indicates it takes quite a bit of reading and study for beginners to gain proficiency in ArcGIS. This is expected, as it would be for any large package.

    I have noticed, however, that almost invariably when I hear criticism that “Manifold’s GUI is difficult and ArcGIS is easy” it comes from someone who has spent a lot of time and effort mastering ArcGIS and has not bothered to spend the same amount of time and effort learning Manif0ld. This is an intellectual disconnect and is not any evidence as to which GUI is easier to learn.

    The best evidence of which GUI is easier to learn usually comes from people who come into the situation cold. Because of the low cost of Manifold, we have very many more people coming into GIS cold than does ESRI. Those who have not tried ESRI of course cannot give a comparative estimate of the relative difficulty of learning ESRI packages compared to Manifold, but we do have a large number of people who have tried to learn ESRI, failed, and then found Manifold easy to learn.

    Any pollster would tell you that there is self-selection bias in such a sample, because obviously those who found ESRI’s GUIs easy to learn would not have been looking for an alternative. So you can only infer so much from such anecdotal evidence. But from years of customer reactions, tech support incidents, many tens of thousands of wishlist items maintained in product planning databases, considering responses only from those people who have learned both ESRI and Manifold the overwhelming majority say they think Manifold is easier to learn and easier to use.

    Your experience and opinion is obviously not with that majority. But, I am not convinced your approach is a typical approach because if you really think serious GIS can be done without reading help files or that significant GIS tasks can be done “in just 5 minutes even by the most inexperienced users”, well, I just don’t believe that is a world view that matches the way most people, inexperienced or not, approach GIS.

    By the way, the focus of all this should not be exclusively on “simple tasks,” because if only “simple tasks” are of interest you need neither Manifold nor ArcGIS. Use MapPoint or some other very simple tool, such as a web-based application. My comments here are about the sophisticated tasks, such as topology overlays of various kinds, for which people need a full-power GIS. Yes, if you want a package that can do only trivial things it is easy to design a GUI that is trivially easy to learn, without requiring the reading of much documentation. I don’t think an exclusive interest in trivial things is the prime focus of the audience that reads this blog.

  79. Vasileios Vlastaras says:

    I am wondering if you ever faced a situation to run a department in which most people are not native English speakers or not English speakers at all !!!
    In such a case I wonder how is it possible for somebody who does not now English to read a help file ! I had to deal with a lot of people in the past who had just very basic understanding in English language and had to perform GIS tasks and I can tell you that they were doing fine with the ArcGIS series. I am not talking for older versions of the Arc/Info software (ie 7.x) that the GUI was built in AML (and didn’t follow windows-like standards) that were difficult to learn.

    I have discussed the issue of functionality efficiency of both Manifold and ArcGIS with people and all the opinions I got so far were against Manifold. I asked a lot of times company owners of whether they would invest in Manifold and the answer was no. Some of them that bought Manifold found out that most of their production-lines were almost destroyed.

    Perhaps you come from an environment that English language is spoken but this is not necessarily the case for every place in the Globe we live :-)

    As far as it concerns my opinion about ‘Users should not read help files these days’, I still believe it. Basically I am a developer. I develop software for GIS more than 10 years now. I have never used the help of Visual Studio for finding out how to perform a task. I am not saying I have never used help for finding out features of a specific language such as C#. But never for finding out how to perform tasks. The Visual Studio GUI is self evident. And this is because it is very well designed. That is the case for ArcGIS. It is self evident. You may end up having a tool window open in which you need to know more about the 3 options that provides in order to perform a task, basically because these 3 options reflect 3 different methods, but you do not need to read help in order to learn how to bring up the tool window ! This is the big difference between Manifold and ArcGIS. You do not need to read help that describes how to bring up tools / windows / etc …

    I am not saying help files should become obsolete. But for sure I am saying that portions of help describing how to end up bringing up tools need to become obsolete. It is more or less the same like having a webpage in which you need to read a help file on order to interact with. Would you use a webpage that would need a helpfile to interact with ?

  80. Dimitri says:

    “I am wondering if you ever faced a situation to run a department in which most people are not native English speakers or not English speakers at all !!!
    In such a case I wonder how is it possible for somebody who does not now English to read a help file ! “

    Well, I myself am not a native English speaker. I remember very well how difficult it was to learn English in school. For the record, Manifold is not available in Russian (my native language), either.

    I routinely find myself in situations where I am surrounded by people who don’t speak or read English. Even in the US it’s now a very typical thing … just the other day I was standing in line at a bank (the Bank of America) when I realized that every sign on the walls – and I mean every sign – was in Spanish. So if you wanted to send funds to Mexico or to take out a loan there were plenty of advertisements aimed at you in Spanish but if you spoke English you’d not be informed of the bank’s latest marketing initiatives. Presumably, your argument is that you’d think the bank’s programs are self-evident enough that if their “GUI” was designed right there’d be no need for translation into Spanish, right? But exhorting someone to take out a loan or send money to Mexico with low fees is not exactly rocket science, yet they still translated all that into Spanish.

    I don’t think that comprehension in some other language has very much to do with GUI design except for packages capable only of very trivial things. Everywhere you go, sophisticated industrial or technical matters beyond the abjectly trivial do not rely upon self-documenting pictograms or other non-text GUIs but expect that national-language documentation will be required to convey non-trivial concepts.

    Consider one example, private aviation: Flying a small Cessna is not particularly difficult (most people solo in around a dozen hours) and the controls of a Cessna are a lot simpler than the controls of even very simple software packages, but I doubt you would find very many people who would criticize the Cessna “GUI” because folks who don’t read English cannot understand English language labels on the controls, an English language pilot’s handbook and an English language textbook for beginning pilots.

    This is a particularly apt analogy because English has become the language of aviation even more so than English has become the language of software. If you want to learn to fly, your best deal and the best path to a career in aviation goes through working familiarity with English.

    “…ArcGIS with people and all the opinions I got so far were against Manifold. I asked a lot of times company owners of whether they would invest in Manifold and the answer was no. Some of them that bought Manifold found out that most of their production-lines were almost destroyed.”

    You know, I just don’t believe that. I get the feeling you are making some of those things up because you like ArcGIS, are very familiar with it, and you don’t want to invest the same amount of effort into Manifold.

    If the use of Manifold could indeed ever even possibly result in something like “most of their production-lines were almost destroyed.” – I mean, if that were even remotely in play, then obviously a total imbecile was in charge of implementation.

    How is it possible for someone other than a total imbecile to “almost destroy” “most production-lines” by trying out a new piece of software? This is not reality in the world of people who are not brain-dead. In the real world, people aquaint themselves with the functions of software so that when they deploy it they know what they are doing.

    Actually, in the real world, people who really have “production-lines” are already using some software item and are almost impossibly unwilling to change.

    Do I believe that someone who is deeply invested into ArcGIS and doesn’t know anything about Manifold will be reluctant to drop ArcGIS and not get into Manifold. Sure! Of course! If they have already purchased ArcGIS and it is working fine for them, why would they need to switch to Manifold?

    So if you asked the question, which do you prefer? of an ArcGIS crowd, well, of course you’d get a predisposition to ArcGIS, just like if you asked that question of a Manifold crowd you’d get a predisposition to Manifold. This proves nothing except that you are not reckoning “selection bias” in your sampling methodology.

    As noted in my earlier posting, the key question is what new users not prejudiced either towards ArcGIS or Manifold prefer, and that hands down seems to be Manifold.

    Here too, there is also selection bias because very few people in their right minds who are familiar with mainstream software quality, capabilities and price/performance would even consider ArcGIS over Manifold. But there are enough samples of initial acquaintance not prejudiced by prior commitments to indicate a strong lead for Manifold. I personally do not think it is so much the GUI as it is the greater level of completion and integration (which, I suppose is also part of the GUI) Manifold enjoys over the more unbundled ArcGIS line of products.

    Regarding ArcGIS being either self-evident or not needing to read documentation to learn to use ArcGIS, I don’t think that applies to 99% of the people who have ever learned to use ArcGIS, whether or not they are new users or experienced users. It’s just not something one hears about ESRI products. In fact, one usually hears the opposite, usually quite caustically expressed.

    I do believe that nonetheless over the years plenty of people have become familiar with ESRI products and now feel very comfortable with them. I also believe that a quite a few of those people may have forgotten just what a struggle it was to learn those ESRI products initially. This is to be expected.

    That’s an effect that is not restricted to ESRI, as I’m sure there are plenty of Manifold people, and AutoCAD people and Visual Studio people and Illustrator people who now praise the GUIs of those products, who feel totally comfortable with them and who now forget just how hard it was initially to get that comfort level.

    But the idea that a sophisticated GIS package is so self-evident you don’t need to read help? I think hands down the experience of most people is against you.

    Are there exceptions? Sure. We have plenty of people who say they learned Manifold instantly, in a matter of minutes and that it was totally self-evident, just like you write about your feelings towards ArcGIS. But I don’t think those people are sufficiently representative to cause manifold.net to stop telling people that to avoid frustration and to gain proficiency as rapidly as possible they should read the documentation in the recommended order.

    Regards to all,

    Dimitri

  81. Rudy says:

    I’ve used all kinds of GIS since the DOS days (15 years and counting) and I can assure you that by far the best GIS software is Maptitude from Caliper Corporation. It is a vector GIS software that can also read and handle raster imagery. It’s native database management is vastly superior to any other GIS (can handle all the TIGER line files of the US in one shot; it can handle one billion!! records and one million fields — unlike MS access that allows only 256 fields). It can read oracle and other DBMS without using programming. An upgrade to TransCAD (another product from Caliper) allows you to perform redistricting using integer programming and other graph theoretic methods (invert matrices and store matrices of 25 K in native format). I can go on and I am happy to debate on this issue. Oh BTY I have an advanced ArcIMS certificate from ESRI for which my previous employer paid 1000s. I use C++ and R to do programming but was never required to program for my GIS stuff. Now that’s a great software. Isn’t it?

    Rudy B., PhD
    Berkeley, CA

  82. Dimitri says:

    For all of its limitations I don’t think anyone would describe Maptitude as other than as a competent and pleasant GIS. It is well-matched to its target market and has a good following.

    Despite its many limitations (no IMS, small number of importable formats, etc.), if you think it is the best GIS ever, well, you are entitled to your opinion. What makes for “best” in someone’s eyes is not necessarily the most features or the most sophisticated capabilities but the right balance for that someone’s particular needs.

    But this bit… “It’s native database management is vastly superior to any other GIS ” …is utterly silly, as Maptitude (for all of its other benefits) is rather well-known for having particularly weak DBMS capabilities.

    I grant you that Maptitude may be improving its products and so is getting better at DBMS, but if memory serves me right (as assisted by a quick review of the Caliper website), it seems that the following gross DBMS limitations to Maptitude still apply:

    To take the most obvious, Maptitude connects to DBMS using ODBC, a terribly obsolete way to go. GIS packages with better DBMS capability can connect using more modern technologies such as OLE DB or ADO .NET. Connecting to SQL Server using OLE DB is about 600 times faster, read/write, than using ODBC, so this is a very big deal.

    Although Maptitude is said to be able to read “oracle spatial tables” (a particularly weird way of phrasing the matter, as if there is a host of “gotcha’s” waiting in the wings), there is no mention of any sophisticated ability to do read/write/edits with many simultaneous users as is normally desired with Oracle Spatial, nor of projection matching on the fly nor of any support for GeoRasters, nor of storing formatting and other key drawing characteristics. All those things are necessary if you are really working with Oracle Spatial as a fully capable client and not just as some “read-only” usage of Oracle as a one-way data source. I grant you it is cool that Maptitude can read Oracle spatial data at all, but to do so in what is apparently a highly limited way is not the way one wins standing as “vastly superior.”

    For that matter, if you really are on top of your DBMS game you’ll be able to read/write/edit not just Oracle spatial but a host of different geometry-in-DBMS data types and DBMS systems, including, for example OGC WKB and WKT, ESRI-style geometry and so on in other DBMS packages, such as SQL Server. Don’t see any of that in Maptitude.

    There is no trace of spatial SQL within Maptitude, something you’d expect any GIS laying claim to serious chops in the DBMS world to offer. If you can’t do spatial SQL you’re just not in the DBMS game in GIS, not even at the beginner level let alone as the best.

    I’ll skip over the hundreds of small, but useful, capabilities that a truly DBMS-capable GIS has and Maptitude does not (example: right click on a column and choose “change type” to instantly change type… ) and conclude with a very telling “big” thing: zero support for 64-bit code and multicore processors. Modern DBMS is multi-threaded. If you can’t run multiple threads to your DBMS connection you’re stuck in the dark ages.

    To shift gears away from DBMS to programming, since your post indicated a certain excitement at not having to do programming to do GIS stuff: not since the dark ages has any modern, interactive GIS required you towrite code to do GIS stuff, so don’t be too excited that this is the case with Maptitude.

    It’s a bit like a country cousin coming to the city and acting astonished there is indoor plumbing. The indoor plumbing is indeed great, but one should not betray too much astonishment at encountering such a convenience, which is taken for granted in modern times. :-)

    I don’t mean any of the above as a slam at Maptitude because I happen to like that software and admire it. I especially admire Maptitude because together with packages like Manifold it helps set the precedent that one can get truly useful and pleasant GIS for a fraction of the cost of legacy stuff like ESRI. People in mainstream software markets understand that, but every bit of re-education helps for those folks still stuck in legacy notions of price/performance. So we should all praise Maptitude for helping move GIS into modern notions of price/performance.

    But on the way to praising Maptitude there is no need for inaccuracy, and suggesting Maptitude is the best GIS there is at DBMS is very far from the truth, hence this correction.

  83. AI says:

    Is ‘Dimitri’ real; would ‘he’ pass the Turing test?

  84. Rudy says:

    Dimitri,

    Buy Maptitude for the Web(TM). It’s just an ad-in and you get your IMS (Do your homework next time before commenting). More later…

    Rudy.

  85. Vasileios Vlastaras says:

    Well, Dimitri seems to work for Manifold, but I think his attitude keeps potential customers away form Manifold. He is quite arrogant, he has an answer for everything, and keeps insulting a lot of commentators. I was talking about GUIs … he managed to sent a reply involving ‘signs in Bank of America written in spanish’ and Cessna airplanes just to support his thoughts ending in some kind of great inference conclusions like:
    “Presumably, your argument is that you’d think the bank’s programs are self-evident enough that if their “GUI” was designed right there’d be no need for translation into Spanish, right ?”

    What can I say ?

    We have a saying in Greece.
    ‘Do not confuse the rollerblade with the granny.’

    Unfortunately I don’t have the time to comment in detail. I am going back to the 500.000 lines of code I implement at the time being …

    Good day to all of you !

  86. josh says:

    Buy Maptitude for the Web(TM). It’s just an ad-in and you get your IMS (Do your homework next time before commenting). More later…

    I think Dimitri was talking about the raves you gave on a $495 product. Take a look at Maptitude for the web pricing: $4000!

    Manifold is $295 and includes the IMS.

    Now, that being said, I think the “Mapplication” that Caliper offers is really good, and perhaps worth the price of admission. Manifold should offer their own “Manications” for the IMS.

  87. Dimitri says:

    “Now, that being said, I think the “Mapplication” that Caliper offers is really good, and perhaps worth the price of admission. Manifold should offer their own “Manications” for the IMS.”

    That’s a fair suggestion, but that would be more the way of legacy markets and not taking advantage of the mainstream.

    One reason I suppose Caliper must offer Mapplications is that the buy-in for their web software (limited though it may be) is so expensive that very few people use it. With so few people using it, there is no broad, horizontal basis of usage that enables third party developers.

    In contrast, you can develop Manifold applications using a $295 Professional Edition (IMS is built-in) and deploy to a web server for a $100 Professional x64 Runtime. Yep, that’s only $100 per web server for full 64-bit (and 32-bit) IMS with unlimited number of users / transactions, unlimited number of sites and unlimited number of processors.

    Because Manifold IMS is part of every Manifold edition from Personal on up, there are vastly more people able to tinker with Manifold IMS than there are any other IMS. So there are lots of people who do their own applications and many who are now offering bits and pieces or entire new templates to other users, either free or for sale. There are many more who create vertical applications they keep proprietary to their own marketing channels.

    A further point is that because Manifold IMS is an integral part of Manifold, any advancements or third party enhancements for Manifold System automatically benefit IMS users. So there are third party products like the Manifold Macro Language (MML) that will help IMS developers as well.

    It is slower path to allow third parties to evolve applications and to fill ecological niches in the market than for Manifold to field such applications. It is always tempting for a company to swoop in and “take the business” that is evidently there. But that would be short sighted and not good for our users in the long run.

    In the long run the mix of commercial and personal contributors steadily increases the number and quality of third party applications. By allowing an unrestricted ecology to thrive without competition in that area from Manifold itself, we encourage rich competition and proliferation of choices. There is also the very real issue that no matter how expert Manifold may be in any one area (such as the creation of a general-purpose GIS), there is no way we can be as expert as all of our customers in the seeming infinity of different applications that are possible.

    Ultimately, although it is a slower process the result is a very rich ecosystem that features more applications, of better quality and at a lower price.

  88. Steve Blogs says:

    Is it just me, or does Manifold sound like a company that is dying for a buy-out? Typical way of trash the biggest player in the market, spin their technology out for a cheaper price and try and make a lot of noise so someone, anyone, will listen in order to raise their profile so they will be bought out.

    If I could put a bet down, I’d say within 2 years they are barely a company, let alone a GIS.

  89. KoS says:

    Rudy…..Mapitude, from what I can tell isn’t widely used. I’m not sure why you make your students beat their heads against it. :)

    Then again, I guess throwing students a curve-ball no and then keeps them on thier toes.

    KoS

  90. KoS says:

    And a correction, if this is a different Rudy, my apologies.

    I never heard of TransCAD or Mapitude until a professor named Rudy showed up on campus this past semester. Of course we had to buy and install all those programs. :)

    To be honest, I’m not too impressed with either. Then again, I don’t use the software all the time.

    And to clarify my comment about widely used, I mean widely used around this part of the world. Maybe else where, but not here. The vast majority of people I ask, they have never heard of the software or only seen advertisment for the products somewhere.

    KoS

  91. Rudy says:

    ‘Beating their heads against it …’ Now I’ve never seen anyone doing that. Maybe they do with ArcGIS or Manifold since nothing seems to get done when one is a novice.

    BTY KoS should look at the syllabus of the GIS course offered by this Rudy (that’s me). We performed redistricting (using integer programming) of schools and congressional districts, used the ‘transportation problem’ in operations research to select optimal location of firms, created fire districts using road network space, did multiple shortest paths (more than 500×500 nodes), inverted matrices to get the Jacobean of the adjacency matrix, created shipping lines to avoid buoys and islands, read GPS outputs directly and displayed time dynamic ‘moving’ maps, converted ArcInfo, MGE, MapInfo, SPSS, SAS, excel TIGER, DLG, ArcView etc files back and forth, build topologies for shapefiles, geocoded a list of addresses based on street addresses for the whole US (try loading all the TIGER street files in one shot in ArcGIS), designed cloverleaf interchanges for interstate roads by editing road files, did multiple weighted buffers across layers (try that w/o coding in ArcGIS), created flood/line of sight maps, created surface maps using mathematical filters like kernel filters, read used files directly from other DBMS w/o any fuss and I can go on and on … all in one semester and that too starting with a new GIS software and w/o any coding. Now were you paying attention in class or was I a bad teacher? If it were the latter then you should not blame the software, should you? Or if you could clarify with your ‘not too impressed’ comment since such comments carry a lot of weight.

    BTY: GIS is used by a tiny miniscule of all the software users so ALL GIS software are obscure to the larger community of computer users. Remember quatro pro, Paradox etc were leaders in their fields and now they ly in software museums…

  92. KoS says:

    Frankly Rudy, I’ve never been in your class. When I took GIS courses we were using Atlas GIS and ArcView 2.x

    Sorry if I wasn’t paying attention, it’s kinda hard if I wasn’t there. :) I’m not sure if you are a bad teacher. Frankly I could give a shit less if you are or are not. It doesn’t affect me on bit. Except when I have to hear students complain about this or that.

    And I don’t need to clarify my statement, “not to o impressed” since that statement stands on it’s own. I did qualify my statement, I haven’t used the software all that much. I’ve taken a peek here and there into it. Especially since it’s loaded on the machines here in the lab.

    But from what little I’ve played with it. For one, it’s not as easy or simple to get up and started with a project, which is similar to my problem with Manifold. Unlike ArcMap or even ArcView, which to me is much easier for a newbie to get up and running. You may not think so, but myself and a number of students think otherwise.

    If you haven’t seen your students beating their heads on the software, then I would guess they are hiding it from you and are too embarressed.

    GIS maybe a tiny portion of the larger community. But Mapitude is a very tiny portion of the GIS community. I can’t think of anyone in this area, in the real-world, using that software package. It may change, but right now it’s not the case. It may be different on the west coast.

    It’s great Mapitude does all that. So can other software. :) Maybe not all in one package.

    Again like I said before, it’s great students are exposed to different softwares. I always tell students it’s more important to understand concepts and functions, then worry about the software program. Because you can apply those concepts and functions to any program. The hard part is finding what you need in a different software package.

    Anyway, done typing, time to go.

    KoS

  93. Dimitri says:

    “For one, it’s not as easy or simple to get up and started with a project, which is similar to my problem with Manifold. Unlike ArcMap or even ArcView, which to me is much easier for a newbie to get up and running. You may not think so, but myself and a number of students think otherwise. “

    Let’s see… “myself and a number of students” ? It appears that somehow in whatever school system you attended on your way to forming opinions about GIS, in addition to not paying attention in GIS class one other aspect of your education to which neither you nor your school system paid attention was grammer.

    I rarely make “ad hominem” comments because they are normally unfair. However, in the case where a critic sets his or her taste or his ability to accurately report the opinions of others then the messanger does indeed become the message and so becomes fair game for examination. In this case the inattention to accurate grammar in your posting seems to echo a disposition to ignore logic and to indulge in a central fallacy in the posting.

    That central fallacy would be “I’m very familiar with Arc (I’ve forgotten how hard it was to learn over the years) so it seems to be easier for beginners to learn when they are boiled in an Arc-centric environment. That I know nothing significant of other packages and have a slovenly unwillingness to learn them proves they are difficult for beginners.”

    In point of fact, for all of its limitations Maptitude is well known for ease of use among people who have first-hand knowledge of several different GIS packages. That’s what keeps the company alive, the packaging of some basic GIS capabilities in a relatively easy to use form. It’s not the broadest, nor the deepest nor the least expensive nor the most powerful, but for what it does it has a well-earned reputation for being easy to learn. Give credit where credit is due.

  94. Dimitri says:

    Ah… almost forgot:

    “Anyway, done typing, time to go.”

    …in the “credit where credit is due” department I have to admit you got that last line right in terms of characterizing your posting.

    That’s a perfect concluding line, exactly calling to mind Truman Capote’s acid dismissal of Keroac’s work with the unforgettable comment, “That’s not writing, that’s typing.” :-)

  95. KoS says:

    Dimitri…..

    I am sooooo glad you are the grammar police. I’ve never like English, so granted it’s a weak spot. I didn’t realize you were an English teacher. If my grammar is not up to your liking, don’t read what I’m typing. And frankly, I wouldn’t criticize anyone’s posts, it’s the kettle calling itself black(don’t you remember apologizing for your English mistakes). Plus since there isn’t an edit button, one can’t edit their mistakes.

    Exposure to products is like personal interactions. It’s within that first 5secs you form a positive or negative impression/opinion of a person. The same applies to software or other items. It may not be right, but it’s how the real-world works.

    Sorry I guess I can’t have a personal opinion different than others. Especially if the opinion is negative towards your software product or others.

    It was very easy to jump in and start using Arc products(non-enterprise apps), again for me(similar comments made by others, o wait, other’s opinions, can’t have that). I didn’t have as much a hassle doing what I needed in Arc compared to Manifold or even Maptitude. There are times where I have to get things done and I don’t have the time to read through help-files or documentation. Time is money. But according to you, it shouldn’t be the case. It’s supposedly one of the easiest to use. It well may be for some.

    If so, why isn’t it being used more widely in the field? Like I said before, no one in the real world in this part of the world(which I’m aware of) uses Maptitude or even Manifold. I would guess your come back would be they are simple minded, too stupid to learn new software on which they haven’t been trained to use or some other BS.

    I don’t mind giving credit were credit is do……but it’s doesn’t deserve the credit, yet. Again my stupid ill-formed opinion.

    It doesn’t mean I can’t or won’t change my mind. I guess I may, once I dig deeper into the software. I know I won’t with Manifold, due to you, Dimitri. Call me whatever you want, narrow-minded or uneducated or ?? But my impression of Manifold software is continuing to be formed by your mouth and my limited exposure to the software. And your mouth keeps reinforcing my low opinion of your software. Plus when asked about which products to use, yours won’t be on the list, even if it’s the best at the given job/task. I know your immediate reaction is so what. Well, don’t be surprised if you don’t land a few sells. I know of a couple organizations looking to buy or upgrade, and I guarantee you the boards will not vote to buy anything Manifold. Maptitude, we’ll keep an open-mind on.

    And please show me where I wasn’t paying attention in class. Like I said before we were using Atlas GIS and Arcview2.x in the class at the time, mid to late 90′s. It’s kinda hard to pay attention to software which wasn’t being used in the class at the time.

    I’ve never said or implied I have a vast knowledge concerning GIS. I don’t, I’m learning each and every day. It’s great Manifold or Maptittude does this or that. Whoopee-do, for what I need, currently, it’s just ok.

    I don’t have any quotes to use. I don’t need to use other people’s words to make myself seem…….whatever.

    KoS

  96. Dimitri says:

    “Plus when asked about which products to use, yours won’t be on the list, even if it’s the best at the given job/task. I know your immediate reaction is so what.”

    Actually, no, my immediate reaction is… perfect! The people who know you in “real life” know perfectly well that you are the sort of person who comes out with gems like…

    “I don’t have the time to read through help-files or documentation. “

    Serious people know that any significant software merits reading through the documentation. This is a sign of professionalism and expertise. Folks who don’t read documentation for significant new things aquire a reputation for “winging it” and for being clueless. Clients have a way of realizing very quickly when they are being advised by a clueless “expert” who is, in fact, “winging it.”

    So, if you wish to acquire or deepen a reputation for being clueless or otherwise uninformed on modern trends go right ahead and bury yourself. Your clients (if you have any) will long thereafter remember it was you who failed to tell them about new technology and that it was you who steered them into paying ten times as much and getting ten times less.

    “no one in the real world in this part of the world(which I’m aware of) uses Maptitude or even Manifold. “

    That tells us little because you seem almost proud of your lack of awareness. If you want to know the lay of the land you don’t ask a blind man.

    Maptitude has been around a long time and sells plenty of licenses. Caliper’s packages, like Maptitude and TransCAD, are very well known in the transportation industry. Caliper products have earned a highly-deserved reputation for ease of use and especially convenient linear referencing capabilities. If you aren’t aware of that you can’t be trusted as someone “in the know.”

    Manifold sells far more product than ESRI in what is by far the largest GIS market on Earth, the market consisting of hundreds of millions of Microsoft users now moving into GIS. ESRI is completely absent from that market. I grant you that ESRI continues to sell more product into legacy GIS markets than Manifold, but it is a sign of insularity not to realize that mainstream markets are very much “the real world.”

    It’s not taking away anything from ESRI (credit where credit is due) to note that ESRI usage is essentially unknown in mainstream markets. ESRI has simply priced itself out of that market, so there’s no suprise that Manifold sells quite well in those mainstream markets and ESRI does not.

    But even if you mean “real world” as shorthand for “legacy GIS market”, even there your comments reveal a certain willingness to ignore logic, a willingness to assume your own conclusion.

    Is it a surprise that someone who has already spend tens of thousands of dollars per seat on a particular vendor’s GIS suite would focus on that vendor? Of course not. If I had spent tens of thousands of dollars per seat, what with licenses, options, maintenance, training, support and all that on a collection of Arcstuff I too would be trying to get the most out of my investment. I’d be flying off to San Diego, I’d be hanging at blogs like this one, all that stuff. Makes sense, right?

    Is the kind of guy who is already deeply invested into legacy software the most likely to try new things? Not usually, but of course a certain percentage are interested in new things. And we win our share of that interest, just enough to get our fair share of the legacy market and to recruit our fair share of highly experienced GIS people to guide the evolution of our products.

    As for implacable economic reality, having the wind in our sails based upon the enormous economy of scale from our participation in mainstream markets allows us to price the product at will even in legacy markets. That’s why you can spend $295 with Manifold and get much more functionality with greater reliability and more power than spending twenty times as much with ESRI.

    Such revolutions in price / performance in computing have a certain inevitability about them. ESRI cannot survive in their present form as prices for their entire market basket of goods drop below $500, and no consultant or prognosticator with predictive abilities exceeding those of the average 12 year old doubts that.

    Once a company backed by mainstream economy of scale introduces revolutionary price / performance into a legacy market the story only goes one way. It may take time, but the end is always the same. It ends with the living fossils formerly inhabiting that legacy market either going out of business or transforming into highly specialized vendors selling the software equivalents of $500 hammers and $2000 toilet seats into federal procurements. (hmm…. just which company beginning with an “E” and ending with an “SRI” does that sound like?…)

    And, the “legacy” market stops being a “legacy” market and becomes yet another part of the mainstream (much to the benefit of long-suffering users) with greatly reduced prices, greatly improved quality and a lot more competition to better serve the customer.

    You can badmouth Maptitude and Manifold all you like, but if anyone is going to survive and thrive as GIS gets freed from the living fossil amber of legacy vendors, it is more likely that new wave vendors like Caliper and Manifold will be the once to thrive at mainstream price / performance levels than it is likely that ESRI could do a triple back flip and re-invent itself as a company able to live within mainstream economics.

    Out of historical curiosity, I know of no instance in computing industry history where a company as far behind in technology and price / performance as ESRI is in legacy GIS markets managed to transform itself into a mainstream competitor after an economy of scale price revolution has occurred. DEC failed, Wang failed and many other companies failed. IBM appears to have succeeded, but on closer examination they really did not stay in the same market but transformed what market they were in (ie, selling off the PC business and becoming, really a big integrator).

    Can anyone cite an example of a dinosaur that reinvented itself to survive a massive change in price / performance to mainstream levels? Is there anyone here who thinks that if the price of all of ArcGIS, plus ArcSDE plus ArcIMS plus ArcObjects would drop to under $500 (with that figure covering all “maintenance” as well), that ESRI could survive?

  97. KoS says:

    Frankly I haven’t read all your crap. I got to the point where you mis-quote me and I skimmed the rest.

    Can’t you read? Or do you need to take things out context just so your e-peen feels bigger? Wait, I forgot English isn’t your native language.

    I never said I didn’t read documents or helps files AT ALL. What did the first part of the sentence say?

    I guess you have never heard of deadlines. Or no excuses for not having the work done. If I have the time, I have no problem reading help-files or documents until my eyes-bleed. Which at times can be very, very therapeutic and enjoyable.

    It’s a waste of my time to figure out some new way or new software when I have a tight deadline. No deadlines or after the fact, then I’m more than happy to search for and play around with new and exciting venues and software.

    Also, I could care less if you think your software or others will push ESRI out of or reduce their market-share. Or even provide a better price structure with a better product. Personally, I’m a big proponent of open-source. I could really give a big crap about the commercial market, not only in GIS but also other markets. But, I have to use what my employer provides or what is decided by the group. When I have the option I use as much open-source as possible.

    Right now ESRI is the big boy in the market, in particular the local market, for good or bad. In the classroom setting, if you are not giving the students the tools to succeed in the real-world/field. Then the students are being short changed. That’s why I mention Manifold and Maptitude isn’t widely used around here. Why make students only learn those two softwares? Note: the majority of the students at the local university stick around this area.

    That isn’t being blind as you put it, it’s being realistic.

    Like I said before. Manifold could be the best at whatever and the cheapest. But I will never use it again or buy the product. It doesn’t matter if I save thousands or even time. So long as you don’t get one red cent, then I’m happy. It’s not about the bottom-line all the time. For me, your recent crap has soured the whole bunch at Manifold. And I’ll bad-mouth your product even more after today. It’s my opinion and I know you don’t like opinions contrary to your own.

    You have made too many assumptions about me. Which is fine, assume too much and it makes an ass out of you.

    What no comments about my grammar? My logic still screwed up? BTW, why are you even responding? I thought I was just typing?

    And yes, I’m a big ass-hole, which is very obvious.

    KoS

  98. Dimitri says:

    OK, I capitulate. You’ve got me there.

    In the interests of fair and honest discourse and total courtesy in the blogosphere, I completely agree with you. :-)

  99. KoS says:

    One more thing D.

    I’ve never said I was “in the know.” What does learning every day mean?

    I did say as far as I know Mapitude and even Manifold isn’t being used around here. It may be, but no one I’ve talked to has seen or used it, beyond seeing an advertisment(mapitude that is, not sure if Manifold does advertise). I have a pretty good idea what is being used in this area, public and private.

    It could be in use around here, those people must be staying in the closest and don’t get out much.

    You need to read and comprehend alittle better. Comrade

    KoS

  100. KoS says:

    I have to eat a big, big, big plate of crow. Must be krama.

    Today I saw an announcement from a local engineering firm asking for job applicants with experience not only in ArcMap, but also TransCAD and Maptitude.

    So, there is at least one around here using the software. The first I’ve seen or heard of. Woot!

    Like I said, learn something new everyday. Now I know a tad more.

    KoS

  101. stu says:

    KoS,

    wow! you have some real anger management issues going on, bud!

    you need to calm down. Manifold is actually a nice little product. Have you used it? And, because you haven’t been able to figure out Dimitri’s schtick, you take everything he says too seriously. He’s obviously saying alot of things tongue and cheek, or exaggerating to make a point.

    that says something about him, not his software. if the software works for you, then why not use it?

  102. Dimitri doesn't work says:

    … he spends all his time typing about how ESRI is an old dinosaur. Manifold really need to update their marketing speak – it still compares itself with versions of ArcView 3x and 8x. Get with the 21st century.

  103. Just noticed... says:

    … they still have James Burns’ “expert” comparison of ESRI vs. Manifold on their website as a client’s discussion. I think he was 1 year out of college when he wrote that.

  104. KoS says:

    hahah anger……I wasn’t angry. I was being blunt. I was only responding in words to his anger. :)

    Words in the written don’t always convey the correct impression of ones true emotions. I’m as guilty as of alot of people who’s typing/words seem anger when we really are not. I guess not using emotes doesn’t help either.

    I guess it’s my shtick, come across as the anger and/or ass-hole type.(sigh) I don’t get anger over this stuff. I get angry over much great issues. Like, govt at all levels and our general state of affairs. Anyway.

    I never threaten him bodily harm or the like. I only threaten, now promise, to not use his software or promote the use of in my dealings and work. It doesn’t mean I’m going to flame him or his company anymore or make it my a mission in life. He did capitulate. :) And I”ll take it, eventhough he really didn’t have to. It’s a free country and internet.

    You may be right about Dimitri’s shtick. But his shtick represents his company. If I don’t like the shtick, I’m not going to buy or deal with it. I’m the customer/consumer and it’s still a free market.

    I don’t like the product, period, it’s my opinion no matter how assine it is. It’s similar to the forming of my opinion of GE based on the overall company google. My overall view of google is negative, so it reflects on to their products. In their case, I still use GE just for the imagery alone. I love looking at high detail in many parts of the world. Like, all those nice pool backyards in northern Tehran.

    There are always exceptions to the golden rule, not using something. Example, one of my bosses came in and told me to install it and use it. Well, I have to take it in the rear or move on to other pastures. Also, my other dealings almost all personal and/or volunteer work, I will not use or promote the software. And again like my bosses, if a board or other group decides to use the software, then I have to decide to take it or move on. More than likely I would focus my energies else where.

    Yes, I have the software. I’ve used version 6 and 7. I still have 7 loaded on one of my home machines. See I wasn’t anger, I haven’t deleted it, yet, and thanks for the reminder. :) And I must say I haven’t used the software in a couple of months.

    I also have at home: TaukGIS, WorldWind, GE(cough), VE, Terragen, Kasmire 3D, lt4x, Quantam GIS, geovista-gis, gmax, 3dem, erdas viewfinder, esri arcexplorer java version and the new arcgis one, mapcruncher, pictometry, grass, geoserver, mapguide, mapserver and arcview 3.2 to name a few from memory. I use some more than others, whether consistantly or here-there. A couple, I haven’t used in ages and would have to relearn. Like mapserver.

    I’m not bring it up to say look at me. I have a big e-peen. Just to point out I have no problem being a non-company man or not thinking out of the box. A blind pig gets an acorn sometimes.

    Hey Dimitri. My grammer and logic getting better? :) I’m practicing. You have given me motivation to improve what I have lacking. Something good came out of it after all.

    KoS

  105. whowho says:

    … they still have James Burns’ “expert” comparison of ESRI vs. Manifold on their website as a client’s discussion. I think he was 1 year out of college when he wrote that.

    definately below the belt.

  106. James says:

    to “Just noticed…”
    Just as a point of interest and clarification – when I wrote it, yes I was a year out of college… but :
    I was 4 years out of university and had been working in the database field for about 8 years and about half of those included GIS and CAD.

    Cheers.

  107. oprah11 says:

    Hey Dimitri. My grammer and logic getting better?

    maybe. but your spelling still needs work – LOL!

    grammar

    James,

    can you make an “all manifold all the time” thread again. then, all these Manifold guys can just write there, rather than hijacking this forum.

    For the 15 Manifold users in existance, they sure do stir up alot of trouble..

  108. Chris C. says:

    ‘May this trend of having civilized discussions continue in the new year!…’

    If only :(