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.
Tags:
108 responses so far ↓
1
Anon
// Dec 21, 2006 at 12:46 am
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
// Dec 21, 2006 at 5:14 am
You paid for something without getting a free demo? Or was the SQL video enough?
3
Petz
// Dec 21, 2006 at 12:11 pm
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
// Dec 21, 2006 at 12:27 pm
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
// Dec 21, 2006 at 12:29 pm
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.
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
// Dec 21, 2006 at 12:46 pm
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
// Dec 21, 2006 at 12:57 pm
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
// Dec 21, 2006 at 1:36 pm
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
// Dec 21, 2006 at 1:40 pm
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.
// Dec 21, 2006 at 2:02 pm
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
// Dec 21, 2006 at 2:08 pm
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
// Dec 21, 2006 at 3:33 pm
Here’s the paper on how to do 100 tasks in ArcGIS & Manifold…
http://dspace.library.cornell.edu/handle/1813/165
13
Jesse
// Dec 21, 2006 at 3:51 pm
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
// Dec 21, 2006 at 4:52 pm
@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
// Dec 21, 2006 at 7:25 pm
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
// Dec 21, 2006 at 8:01 pm
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
// Dec 21, 2006 at 8:06 pm
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
// Dec 21, 2006 at 8:49 pm
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
// Dec 21, 2006 at 10:37 pm
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
// Dec 22, 2006 at 12:56 am
ArcGIS and Manifold both suck.
ArcInfo workstation line commands is the only way to go!
KoS
21
Dimitri
// Dec 22, 2006 at 3:05 am
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
// Dec 22, 2006 at 3:29 am
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
// Dec 22, 2006 at 3:43 am
Dimitri, the day I see you leave an one sentence response I’ll roll over and die.
24
Dimitri
// Dec 22, 2006 at 8:14 pm
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
// Dec 22, 2006 at 9:49 pm
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
// Dec 22, 2006 at 11:00 pm
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
// Dec 23, 2006 at 12:20 am
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
// Dec 23, 2006 at 12:30 am
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
// Dec 23, 2006 at 12:35 am
“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
// Dec 23, 2006 at 5:28 am
“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
// Dec 23, 2006 at 7:24 am
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.
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.
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.
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.
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.
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.
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.
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
// Dec 23, 2006 at 8:35 am
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
// Dec 23, 2006 at 8:36 am
Ok that is weird……my post should have shown up after Leslie’s. It’s before his?
KoS
34
James Fee
// Dec 23, 2006 at 8:42 am
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
// Dec 23, 2006 at 11:21 am
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
// Dec 23, 2006 at 4:26 pm
“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
// Dec 23, 2006 at 6:21 pm
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.
Sentence structure isn’t important in technology as much as getting the actual terms correct.
What “Microsoft language” does Manifold use that ESRI does not? I’m not sure what you are going after here.
Poorly written documentation is no excuse. You cannot not write ActiveX scripts, but you can write Active Scripting scripts.
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’m still not buying that example. ESRI made those choices in 1998/2000. When better solutions became available they offered them.
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?
Um you have got to be kidding me? That is documentation?
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.
You didn’t show me where .mdb has gone “end of life”. Please I ask again show me where that happened.
38
James Fee
// Dec 23, 2006 at 6:22 pm
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
// Dec 25, 2006 at 12:39 am
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
// Dec 25, 2006 at 2:01 am
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
// Dec 25, 2006 at 10:59 am
You would be incorrect. ESRI has offered VB/JScript as an option since ArcGIS 8 came out. That would be before 2000.
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.
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
// Dec 25, 2006 at 11:10 pm
> 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
// Dec 25, 2006 at 11:27 pm
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
// Dec 26, 2006 at 8:23 am
I mean that ArcGIS allowed and allows running of Active Scripts from the main user interface.
No, but…
Since ArcGIS 9
Yes
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…)
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
// Dec 26, 2006 at 8:30 am
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.
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 The Memory Leak » Blog Archive » Flu Geography // Dec 26, 2006 at 10:11 am
[...] 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
// Dec 26, 2006 at 10:29 am
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
// Dec 26, 2006 at 1:22 pm
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
// Dec 26, 2006 at 1:28 pm
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
// Dec 26, 2006 at 1:37 pm
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򽯨
2. 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
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
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
// Dec 26, 2006 at 4:13 pm
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
// Dec 26, 2006 at 4:54 pm
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
// Dec 26, 2006 at 7:21 pm
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 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.
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.
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.