Subscribe to this thread
Home - General / All posts - ArcGIS 9.3 vrs Manifold 8/9...
tomasfa
182 post(s)
#27-Feb-09 08:00

Hi guys!.

One very common question in the Forum is: where can we find a comparison between ArcGis and Manifold. We usually need that as GIS professionals for different purposes, benchmarking the software, justify the choice to our boss, explain why choose Manifold over the competition and how can a low cost software CAN DO SO MUCH.

So, I took the task to assemble a head to head comparison based on the functionality matrix given by the competition. I need some help to finish it. I don't use ArcGIS at all! Some of the functionality or features I don't know them. They are marked in yellow and green. Those rows I need assistance to correctly fill them up.

I upload it for the entire Community, so we can defend our choice of GIS software, more easily and with facts. Because some times is just words, until we can get the customer on the desk and show them live... that by the way is the best way to Convert them into Manifold followers.

Also I was doing it, based on Manifold 8, and if some of you can add some extra input about M9 that can improve the comparison, that would be great. This functionality matrix is based on ArcGIS 9.3. the latest. It would be great now that M9 is near, that we come out with such an up to date comparison...

The document is free for all of us, I hope it helps the community. If some one considers adding other columns, to the file GO AHEAD, lets make it even better. For example, we could add a Extension Column, so we know when ArcGIS is talking about a feature in one of its many extensions (Spatial Analysis, Network Analysis, etc.)

That is out of my reach, I don't have the knowledge of that tool to do it. But, some of you definately DO.

Also please excuse me of any mistakes in the comparison, if you do find them please correct them and let me know. Once finished, PLEASE UPLOADED IT BACK TO SHARE WITH ALL OF US.

Best wishes,

Tomas GISP.

San Jose, Costa Rica

www.gisits.com

Attachments:
ArcGISvrsManifold_V2.xlsx

vincent

1,972 post(s)
#27-Feb-09 08:13

Wow, it's a missionnary task !

I notice there is nothing about IMS, which is included in almost Manifold version.

tomasfa
182 post(s)
#27-Feb-09 08:22

You are right!

Its because I used ESRI's functionality matrix as base document and they didn't include any IMS features and probably others. If some of you want to integrate those aspects of Manifold, that should be on the document, please by all means add them.

This is a useful document for the Community, let create the BEST comparison ever, specially now, that is coming out the Best Manifold version ever.... M9.....

Mike Pelletier

2,122 post(s)
#27-Feb-09 08:45

Vincent's comment about IMS applies to many other things. There would need to be a large section that shows all the things you can do in Manifold that cannot be done in ESRI such as the many database manipulations functions on the transform toolbar for tables, spatial SQL, etc. etc. The table would probably end up 1/2 again as long.

I think a liberal use of Not Applicable in the Manifold column is needed for many of ESRI's entries. Also, its so difficult to put some items into a single line of text as it doesn't tell the story well. For example, the Manifold GUI making many tasks so much quicker. These should really be rated rather than a simple check box.

There's no way you will get this filled out for version 9 until its released unless Manifold policy flips. I sympathize with your position though, because waiting around for 9 isn't very productive especially because it could be a long way off.

teconner7396 post(s)
#27-Feb-09 13:58

Vincent's comment about IMS applies to many other things. There would need to be a large section that shows all the things you can do in Manifold that cannot be done in ESRI such as the many database manipulations functions on the transform toolbar for tables, spatial SQL, etc. etc. The table would probably end up 1/2 again as long.

To be honest, there isn't a whole lot that Manifold can do that can't be accomplished by one of ESRI's products, including IMS. Possibly spatial SQL as you cited, but many of the ESRI functions can accomplish the same things that can be accomplished using spatial SQL. Perhaps a more comparable comparison would be made between Manifold Personal Edition and ArcGIS/ArcView liscense. The list of things ESRI products can do that Manifold cannot do would be immense. This isn't to knock on Manifold, it's just a fact. A fact, largely due to ESRI's 30 year head start, immense budget, and more than 4,000 employees. Hopefully, the next few years will significantly reduce the gap between the two companies.

vincent

1,972 post(s)
#27-Feb-09 14:33

Perhaps a more comparable comparison would be made between Manifold Personal Edition and ArcGIS/ArcView liscense.

From a business point of view, I think it is better to compare what you can get for 1000$ with ESRI and Manifold. This is more fair.

That being said, I cannot choose between Manifold and ArcView 9.x, neither recommend one more than the other. They are complementary. I cannot think of quitting one.

teconner7396 post(s)
#01-Mar-09 10:29

From a business point of view, I think it is better to compare what you can get for 1000$ with ESRI and Manifold. This is more fair.

That being said, I cannot choose between Manifold and ArcView 9.x, neither recommend one more than the other. They are complementary. I cannot think of quitting one.

If this were the case, then Manifold wins hands down because the only product ESRI seems to offer at or below that price is ArcGIS Explorer. If we set the price at $1,500 then we are comparing ArcGIS - ArcView to Manifold Ultimate 64x. The two would be very complementary, but which one would take the lead, that is which data storage model would be used. The ESRI geodatabase or Manifold in combo with another RDBMS? If you are partial to ESRI, you are probably going to create a file geodatabase and export shapefiles to do the many Manifold functions that can only be accomplished in ESRI with advanced licensing or extensions. Manifold cannot read the file geodatabase format, and doesn't know what to do with curves in a geodatabase if your using a personal geodatabase. If your partial to Manifold, you are probably digitizing your data in ArcGIS and exporting it to a shapefile to be imported to Manifold. You are likely to export the data from Manifold into a ESRI for a lot of the cartographic work.

Dimitri


7,413 post(s)
#28-Feb-09 11:36

The list of things ESRI products can do that Manifold cannot do would be immense. This isn't to knock on Manifold, it's just a fact. A fact, largely due to ESRI's 30 year head start, immense budget, and more than 4,000 employees. Hopefully, the next few years will significantly reduce the gap between the two companies.

Well, that could just as accurately be rewritten to:

The list of things Manifold products can do that ESRI cannot do would be immense. This isn't to knock on ESRI, it's just a fact. A fact, largely due to Manifold's 10 year head start in technology, immense development budget, and more employees doing actual product development. Hopefully, the next few years will significantly increase the gap between the two companies as Manifold pulls further ahead.

Both of the above can be true at the same time because both ESRI and Manifold product families are truly immense in breadth and depth, taking several thousand pages in either case to document. It is expected with any such broad and deep and diverse product families that both will do what most people in general-purpose professional GIS want to accomplish, but that on the way to accomplishing that general end there will be many things that ESRI does which Manifold does not and also that there will be many things that Manifold does that ESRI does not. Both companies have far too many features to expect an exact overlap, and given the large number of features any non-intersecting product regions on both sides will include large numbers.

However, for all that, the general opinion of those who know both ESRI and Manifold very well seems fairly strong that at any given cut through the product families the Manifold option will in general provide greater breadth and depth of capabilities at a far lower price. Almost without exception, when ESRI people learn Manifold they will often comment that Manifold does an absolutely astonishing number of things and does many of them better than ESRI. How can that be? The quotation at the top of this letter provides some clues: 30 years, big budget and herds of employees are not positives in this case.

Starting 30 years earlier when the competition is all about rapidly changing technology can often be a negative, not a positive. In the audio player industry, for example, tinkering around with reel-to-reel tape recorders or cassette tapes 30 years ago just builds a lot of legacy inertia that does not help you out-iPod Apple in modern technology. If you look at ESRI's technology, that's through and through the case with them where they cling to horrifically obsolete technology.

Good example are the paleo-GIS relics of shapefiles within today's SDE, SDE in general, a non-integrated architecture, inability to utilize modern hardware and ESRI's return to time-sharing instead of distributed desktop processing. Time-sharing became obsolete almost 30 years to the day when in 1979 microprocessors started their epic campaign to extinguish time-sharing. I guess ESRI didn't get the memo. They struggle with something as elementary as going 64-bit. They don't do modern things like CUDA at all.

I'll take the next two points in reverse order: 4,000 employees is a harsh negative if 3,980 of those employees are devoted to activities other than core development on your core product. ESRI's actual product development team is tiny because they put most of their efforts into other activities, such as very large marketing and sales forces devoted to spending immense amounts of money selling tiny numbers of hyper-expensive products. Much of what they do put into "engineering" goes not into forward development of their core products but rather into applying twists of baling wire and duct tape to patch up living fossil technology.

As for very large budgets, if the amount of money one burned up was a metric of quality, we'd all be rushing to use the Post Office instead of Federal Express and the expression "five hundred dollar hammers and two thousand dollar toilet seats" would not have entered the public lexicon. I have run development efforts that had one hundred million dollar plus budgets backed by multi-billion dollar investment into collateral infrastructure. I can assure you that the Great Rule of government financing applies to such efforts as well: "All the money that is budgeted will get spent." But there is no Great Rule that says it will get spent effectively or wisely.

In fact, the usual case is that huge amounts of excess cash will be spent foolishly and with poor efficiency, whether you are talking about government or private industry. In both cases, absolute budget power corrupts absolutely and usually leads to nothing but Caligulan bacchanals at the expense of either taxpayers or shareholders. I'm not throwing stones here, by the way, because I've done that too. It's amazing how easy it is when you have a hundred million or so in the budget to convince yourself that dialing back a tradeshow display from costing $700,000 to a mere $600,000 is an example of exemplary fiscal restraint.

In point of fact, if you know what you are doing and you are working with an elite team on well-focussed objectives, a few tens of millions is plenty to do whatever you want. Apply more money than that and it just gets wasted on stupid stuff like too many private espresso bars, pinball machines and other stupid toys that people get into when they don't really know what they are doing well enough to become obsessed by the real work of the enterprise.

So how does Manifold do much more than ESRI at a fraction of the cost? Easy.

The use of more modern technology in Manifold products allows Manifold to deliver much greater reliability, more power, greater sophistication and accuracy of algorithms and greater flexibility all at a much lower price than ESRI products. That's how a $445 Manifold Enterprise x64 license does much more for most real-life users than a basket of ESRI products costing $30,000, such as ArcGIS, ArcGIS Server, ArcSDE, ArcIMS, ArcMap, ArcInfo, ArcObjects and the like, or whatever they are calling those products these days.

Does any of that mean that there aren't things ESRI does which Manifold does not, or that it's not highly instructive to learn from ESRI if you are setting out to do a better job? Of course not. The key there, though, is to focus on the general tasks and activities in government and industry and science which although evolving are more or less continuing over the past few decades and into the future. ESRI has a lot of features accreted in their products to serve such activities and the ones that still make sense are the ones to support with newer, more performant, more reliable, more flexible, more cost-effective technology.

An addendum: folks who have run successful development teams will rightly point to the tiny size of ESRI's core development teams as a plus. That's true, and if you really know what you are doing you know that given the limits of organization you can't make really good development go ten times faster by throwing 1000 guys at a task instead of 100. As Microsoft has demonstrated with Windows, even if you are really good at development management that doesn't work. Many of the truly outstanding technologies of our era have been created by very small teams. UNIX, for example, was just a couple of guys at first that grew into a core team of about five or ten guys. Add too many heads and you run into the limits of organization, kind of like physical limits brought the end of Moore's law in random-logic chips.

But you can get past that a bit with careful modularization, sort of applying parallelism in development, but only if the effort is very well conceived and managed overall. And that's where the 3,980 other guys at ESRI spoil the broth. When the company has headcount overwhelmingly in areas other than development, that's where all the mindshare goes. If you have 2000 guys in marketing and 20 guys in core development when the core development guys want to bite off the pain of doing some new development right but that conflicts with the near-term objectives of the 2000 guys in marketing, well, guess who wins the vote? That's why you see ESRI guided by the inertia and demands of just about everything except better product at a lower cost.

This can be changed, of course, in those companies where the non-development people have the longer time scales and greater vision to put a better product at a lower cost first. But given human nature that's very hard to achieve in the scrum of day to day business activities where very short term objectives often rule.

thegitksan26 post(s)
#28-Feb-09 21:37

Dmitri, that was a well thought out argument, and definitely made me think. Thanks for making the time to respond so thoughtfully.

Russell in Canada.


Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

teconner7396 post(s)
#01-Mar-09 10:05

Both of the above can be true at the same time because both ESRI and Manifold product families are truly immense in breadth and depth, taking several thousand pages in either case to document. It is expected with any such broad and deep and diverse product families that both will do what most people in general-purpose professional GIS want to accomplish, but that on the way to accomplishing that general end there will be many things that ESRI does which Manifold does not and also that there will be many things that Manifold does that ESRI does not. Both companies have far too many features to expect an exact overlap, and given the large number of features any non-intersecting product regions on both sides will include large numbers.

Of course Manifold is immense, but the reality is that there are entire geographic data models that Manifold does not support.There is no TIN model and raster modeling is limited to images and surfaces.One cannot reliably represent features with associated attributes in a raster data model in Manifold.Speaking of documentation, ESRI provides one of the best help solutions of any software product I have ever used.If one doesn’t know what a tool does, the just click on “the what is this” tool and you get the answer.If you do not know what a menu command does, just move the mouse over the menu item and press shift + F1 and you get the answer.Every function is very well documented and you can quickly access a brief description by pressing a help command button as you used the toolbox or menu function. Perhaps this is what the 3,979th ESRI employee has been up to lately.

However, for all that, the general opinion of those who know both ESRI and Manifold very well seems fairly strong that at any given cut through the product families the Manifold option will in general provide greater breadth and depth of capabilities at a far lower price.

Let’s exclude price because the original argument was about functionality.Let’s take one of the most basic GIS functions such as data creation and editing and compare the products.First, ESRI offers the ability to create features using parametric curves; Manifold offers no support for curves.ESRI offers tools such as the trace tool where features can be created tracing other features, with the option to create features by tracing with an applied offset.Manifold offers no such capability.ESRI offers access keys such as pan, zoom, show vertices, etc. that are active while one is digitizing a feature.Manifold does not provide this functionality, and panning and zooming while creating a feature is a nightmare.ESRI offers a snapping environment that can be highly customized to one’s needs.Snapping can be applied only to certain layers and priorities are assigned to features in different layers.Manifold snapping is either on or off and snaps to all drawings that are visible.ESRI sketch tools include tools such as Distance-Distance, Direction-Distance, Intersection, Midpoint, End point arc, Tangent curve, etc. that are very useful in creating features.Manifold’s set of basic Insert tools have remained basically the same throughout the past 10 years.If one were digitizing building foot prints with 90 degree angles for example from an aerial image, one could easily create these features in ESRI using different combinations such as the Rotate Data Frame tool or the constraints in the context menu of the sketch tool.It is nearly impossible to accurately and quickly do this simple and highly common task in Manifold.ESRI offers the ability to create features applying constraints such as parallel, perpendicular, or segment deflection to both existing features and the sketch itself.Manifold does not offer this feature.There are also vast differences in areas such as topological integrity checks.The ESRI topology rules are much more extensive and one can be 100% certain of the topological integrity of a feature class when applying and running the various topology functions in ESRI.Topology can also be maintained between different layers in ESRI.Manifold is limited in topology functions.One can only check topology between features in a single Drawing and only within an applied precision.If there are gaps in an ESRI feature class, they will be discovered by the topology functions.In Manifold, the gaps may or may not be discovered depending on a number of factors.Then there are other aspects such as subtypes, domains, etc. but why go on?I doubt very seriously that many people that have used a large number of ESRI products lately would agree that Manifold provides greater breadth and depth than ESRI. Perhaps many would if they only used the ArcView liscense without any extensions. I just don’t see any good in making these claims that Manifold has equaled or surpassed ESRI in functionality or that it has a better workflow design when they are not true.How are these claims going to advance the Manifold product?If everyone is happy with the functionality of Manifold and no one is critical, why change anything? Personally, I would like to see Manifold provide a better product than ESRI, who wouldn't? This will never happen if people really think that the current product is equal to ESRI's current products.

Mike Pelletier

2,122 post(s)
#02-Mar-09 09:52

I like how Vincent said Manifold and ESRI are complementary and I'd agree with teconner73 that at this point you can much more with the full line of ESRI products than you can with Manifold. But what you can do with Manifold is generally so much more enjoyablly done in Manifold.

While time can be a burden as Dimitri points out for software that doesn't keep infrastructure up-to-date, time is also surely behind Manifold's lack of progress in clearly sub par areas such as CAD capabilities. So hopefully a bit more time will see version 9 released and many of the deficiencies listed above removed.

vincent

1,972 post(s)
#02-Mar-09 10:14

teconner73: Manifold snapping is either on or off and snaps to all drawings that are visible

False, see layers restrictions.

Mike: But what you can do with Manifold is generally so much more enjoyablly done in Manifold.

I do not agree. Having to "CTRL+ALT+Click" every object is annoying and will keep me off Manifold for manual editing task forever.

Everything that can be scripted is more enjoyable in Manifold, I agree.

Mike Pelletier

2,122 post(s)
#02-Mar-09 10:52

Certainly not everything is more enjoyable. Having to "CTRL+ALT+Click" every object also makes it hard to eat lunch while editing :-)

rfriedman
243 post(s)
#02-Mar-09 14:43

It's easy to eat and edit, just "CTRL+ALT" with your free hand, and left click the mouse with your elbow or nose ... OK ... so maybe that doesn't work so well.

But "CTRL+ALT+Click" ensures that you really want to edit the feature in question. I have no idea how many times the double click method in ArcGIS has gotten "out of sunc" or I barley missed the vertex I wanted to move, and moved the whole object when I didn't want to.

I've grown quite fond of the "CTRL+ALT+Click" way of editing. Like anything else, you do it enough times, it becomes second nature.

vincent

1,972 post(s)
#02-Mar-09 15:06

It doesn't exist in ESRI, because ESRI products cost an arm. You have to be able to work with the remainder.

mikedufty

871 post(s)
#02-Mar-09 16:29

Manifold does not provide this functionality, and panning and zooming while creating a feature is a nightmare

Actually + and - on the numeric keypad pan and zoom simultaneously while creating and works really well. It's just really non obvious to discover as they operate differently while creating a feature to at other times.

I think this makes it not a nightmare, though still not as nice as the pan with the wheel button feature in autocad, which is really pleasant to pan around and edit in for the brief minutes between crashes.

ColinD

2,081 post(s)
#02-Mar-09 16:50

not as nice as the pan with the wheel button feature

Interesting, I use + & - and it's not too bad but I did put a wish list item in a few weeks ago for wheel operated pan.


Aussie Nature Shots

johnrobot
306 post(s)
#03-Mar-09 01:13

teconner73, have you written to sales about these missing features? I send them perhaps one e-mail a day with suggestions and I would like to suggest that you do your best to keep them from going lazy.

Dimitri


7,413 post(s)
#03-Mar-09 22:28

teconner, I respect your comments but I think perhaps you miss my point. Let me try to make my point better. ESRI and Manifold are different products. Both are very large products. If you imagine different features as points, you can draw Venn diagrams to show the features that Manifold has and the features that ESRI has. Suppose you draw two circles, one to show the features that Manifold has and one to show the features that ESRI has. Those features will overlap where they cover features both product families have in common. But there will be parts of the Manifold circle not covered by ESRI, and there will be parts of the ESRI circle not covered by Manifold.

One of the points of my posting was that if there are very many features in play and huge numbers of features covered by Manifold and by ESRI, well, then it stands to reason that the features in either product not covered by the other will be large numbers as well. Enumerating some features in ESRI you like that are not in Manifold is neither a confirmation nor a denial of that thesis, no more than enumerating the many features in Manifold not in ESRI either confirms or denys that point. You can prove that for yourself by enumerating some of the zillions of things in Manifold that ESRI does not have: do your own thought experiment and list, say, the first 200 items Manifold has ESRI does not. Begin with things ESRI people have never heard of, like the Decision Support System queries. Or active columns. Or Selectback. Or a development environment... like the lack of syntax coloring in the ESRI script editor that isn't built in, the debugger that doesn't exist, the lack of IronPython and similar. Or, how many functions exist in Manifold's spatial SQL that don't exist in ESRI? Odd there's no ability to connect native to spatial DBMS, no IMS in ArcView, etc., etc.

The point is that after you go through all that you'll convince yourself that listing a few hundred items on the one side or the other doesn't change the basic lay of the land in that both systems comprise what most people need to do for their GIS functions. Sure, there are people on both sides who use something that is in their product's Venn diagram coverage not in the other, but most people fall somewhere in the common ground, which is why the products tend to overlap in that common ground.

But for all that Manifold in general has far more feature set and more sophisticated stuff. An example of the latter would be ESRI's limitations in things like topology overlays, which don't apply to Manifold. ESRI has a lot of bizarre limitations (no overlapping areas, etc.) and strange limitations in its ability to handle metrics that simply don't limit you in Manifold.

Another example would be the various antique ESRI architectural approaches, such as their inability to do topology on the fly, or the use of rasters with attributes to represent features, something you'd think would have died out with GRASS once the world learned how to do vectors properly. Yeah, sure, they have features to support that stuff, but who cares? It's like someone proudly announcing their cassette tape player has an auto-rewind feature, as if that's something that's a big deal in a world where people use iPods. If you are in the ESRI world I appreciate that is important to you. But it's not at all important to the much bigger world of people doing GIS in general who don't care whether they use MapInfo or ESRI or Manifold or whatever, in which case people often like a different way of doing things if it works better.

Manifold often performs the same task, but differently. For example, why have a trace tool with offset when it is simpler to copy a feature and paste it and then offset it as Manifold does? That's a lot easier than tracing it.

I doubt very seriously that many people that have used a large number of ESRI products lately would agree that Manifold provides greater breadth and depth than ESRI. Perhaps many would if they only used the ArcView liscense without any extensions.

ESRI has relatively few users as a matter of raw numbers, and most of that small number uses ArcView and has not acquired a full collection of ESRI products. As a matter of arithmetic, virtually no one, a few tens of thousands, has encountered the full collection of ESRI products. So almost always when an "ESRI user" compares Manifold to what they have on hand from ESRI they conclude that Manifold is hugely more in breadth and depth. You may disagree with their judgment, but people tend to look at broad comparisons such as inclusion of things like IMS, a development environment, the spatial SQL, the languages, the raster and vector stuff, the endless table and DBMS items. They also look at depth. In terms of depth, it's the cold steel reliability of Manifold's geometry algorithms over ESRI's, as can be seen in things like the topoloogy overlays, the immense sophistication of Manifold's spatial SQL, the fineness and completeness of how Manifold does things like maintain coordinate system when you are copying and pasting and cutting and pasting and all that. Even those who have the full set of ESRI products usually remark they prefer the greater depth and breadth in Manifold. My own guess is that half the time that comment comes out not so much because anyone has done a feature count, but simply because people prefer the greater integration of Manifold (anyone who has tried to stich comparable functionality out of ArcObjects, ArcSDE, ArcIMS and the like knows what I mean) [I use the classic names since more people are familiar with them than the newer names]. It is, no exaggeration, tremendously convenient to have that integration in Manifold.

I freely grant that if there's something you really like in ESRI that's not in Manifold, or you don't like the way Manifold does something you really like in ESRI, well, you'll feel annoyed at that. That's OK and part of the way it goes. But keep in mind that there are plenty of people who feel exactly that way about something they like in Manifold, like image servers or spatial SQL, that's not in ESRI.

Can't resist one last observation, about popups from dialogs into Help: that's often a sign of a slowly evolving product and engineers who are not using their time to maximum technical effect. it's very easy to do if you don't mind putting some extra time (it's not a headcount thing but a time thing) into the development cycle. It also takes mindshare and throughput out of your developers. Remember, every minute your engineers spend on something other than development, whether it is filling out an expense report or embedding a popup reference, is one less minute they have to add or improve a capability. Given that Help on every dialog is available it seems to me it would be better to have engineers not spend any cycles on providing an alternate path when they could be extending the product in fundamental ways, so long as they have something that's more important to do. In ESRI's case, for example, I think their users would have hands down preferred that ESRI had spent that same time into going 64-bit than into doing popup help tips on things already covered in Help.

I also note that such popup help tips are often moronically trivial: "The Cancel button is used to cancel out of this dialog." In the case of reasonably sophisticated controls, you want some real discussion. May as well get that in Help.

teconner7396 post(s)
#21-Mar-09 17:32

But for all that Manifold in general has far more feature set and more sophisticated stuff. An example of the latter would be ESRI's limitations in things like topology overlays, which don't apply to Manifold.

How is ESRI limited compared to Manifold in toplogy overlay? ESRI offers the same Identity, Intersect, Union, and Update that Manifold offers, however ESRI adds additional topology overlay support with symmetrical difference and erase procedures.

ESRI has a lot of bizarre limitations (no overlapping areas, etc.) and strange limitations in its ability to handle metrics that simply don't limit you in Manifold.

Another example would be the various antique ESRI architectural approaches, such as their inability to do topology on the fly

These limitations haven't existed since the widespread used of the antiquated ArcInfo coverage data model. Areas can indeed overlap in both shapefiles and ESRI geodatabase feature classes. Also, topology is only stored in the coverage data model. ArcGIS does perform "toplogy on the fly."

or the use of rasters with attributes to represent features, something you'd think would have died out with GRASS once the world learned how to do vectors properly. Yeah, sure, they have features to support that stuff, but who cares?

Anyone that performs many of the myriad of raster analysis functions that cannot be performed with vector data? I would think that given the intense focus on CUDA development, it would be in Manifold's best interest to add as much raster analysis functionality as one could possibly dream up. So what if a program can perform calculations 1000 times faster than another if it can only perform 1/10th of the functions one needs?

Manifold often performs the same task, but differently. For example, why have a trace tool with offset when it is simpler to copy a feature and paste it and then offset it as Manifold does? That's a lot easier than tracing it.

It's not the same task. Both Manifold and ArcGIS can copy and paste features from one drawing/feature class to another with similar results. Suppose for a moment that you wanted to create a fence around the boundary of a parcel of land. If you were going to copy/paste, first you would have to deal with the attributes. You don't want the fence drawing to be filled with the attributes of the land drawing so you have to be sure to deselect the attributes. Now you have a polygon in your drawing that has to be converted to a line using another step, then you have to delete the polygon. This could have been accomplished in one step with the trace tool in ArcGIS. So you can do it a little facter in ArcGIS what's the big deal?

Now suppose that you want to create the same fence, yet this time the fence is inset 5 feet from the parcel boundary. Now you have to repeat the previous steps then attemp to accurately scale the polygon so that it is offset 5 feet from the parcel boundary. Not a simple task that can be performed easily or accurately through copy/paste.

What if we now have a fence that is on the boundary of a parcel of land running east for 20ft. turns south and perpendicular to the boundary for 5ft, turns east to run parallel and offset 5 ft. from the boundary for 30ft, then is interrupted by a ditch for 5 ft., picks up on the boundary and continues along the boundary until it begins to follow a path unrelated to the boundary crosses the parcel boundary and begins to follow a road centerline at an offset of 15 ft from the road centerline? How is copy/paste going to create this fence? How would you accurately create the fence if you tried to digitize it with the create line tool?

It seems like creating more indepth fuctionality for certain functions such as the object creation tools would be a rather simple and quick task relative to the other tasks the Manifold development team has accomplished where the benefits would enourmously outway the costs.

gxdata

745 post(s)
#05-Mar-09 16:15
Let’s exclude price because the original argument was about functionality. Let’s take one of the most basic GIS functions such as data creation and editing and compare the products.

..etc (my emphasis)

Thanks for those comparisons, teconner73.

I find these same shortcomings in Manifold, from the perspective of a geologist (rather than yours = ? civil engineering). Tracing, data creation, etc are fundamental.

I just don’t see any good in making these claims that Manifold has equaled or surpassed ESRI in functionality or that it has a better workflow design when they are not true. How are these claims going to advance the Manifold product?

I agree entirely. Yes, I know people have their personal styles in writing on forums, but Dimitri's one of attempting to exhaust the opposition by length of reply - while ignoring what I at least think are valid criticisms, put forward in good faith - I find very tiresome.

On Help: I find ESRI's Help to be very informative and useful - even for a non-ESRI user (ie, I don't use ArcXX, in day-to-day work). It's well-organized, easy to read and as you say available during use of the product.

Sure, it's amusing to read the Manifold documentation at times, but ....

Of course I'm not criticising Manifold from a value for money view, nor do I think it's greatly inferior. But there are gaps in Manifold's repertoire that are almost but not quite show-stoppers, and there does not seem to be any desire for those to be included in its feature set during the past 4 years.


~Ian Thomas
Dimitri


7,413 post(s)
#05-Mar-09 17:50

Dimitri's one of attempting to exhaust the opposition by length of reply - while ignoring what I at least think are valid criticisms, put forward in good faith

Well, my replies look at different sides of an issue as a matter of education. You're free to add me to your blacklist if you don't find them worthwhile or to skip over my postings. But if you disagree you should at least have the courtesy not to misrepresent what I wrote. Let's see, I wrote...

I freely grant that if there's something you really like in ESRI that's not in Manifold, or you don't like the way Manifold does something you really like in ESRI, well, you'll feel annoyed at that. That's OK and part of the way it goes. But keep in mind that there are plenty of people who feel exactly that way about something they like in Manifold, like image servers or spatial SQL, that's not in ESRI.

...sounds like instead of "ignoring valid criticisms" I wrote exactly the opposite, saying, sure, someone might have criticisms but it is important to note that other people may have very different views. It's not me you have to convince but other users who might not share your priorities.

I respect the taste and needs of users, so I don't get heated up about individual features because through long experience I know there are many different constituencies who often have very different priorities. My main interest is making sure that what most people want gets done. Which brings me to...

But there are gaps in Manifold's repertoire that are almost but not quite show-stoppers, and there does not seem to be any desire for those to be included in its feature set during the past 4 years.

Well, if you have in mind something that is missing in the "valid criticism" department, please post the text of the suggestion you sent in for whatever is the item you want. I ask that because if you want to convince other readers your priorities are the right ones toward which the big ship of Engineering should steered, you owe to them when you ask them to drop their priorities to show that you have taken your own priorities seriously enough to at least cast a vote in favor of them.

It's a rare thing that a company offers to put millions of lines of code, years of engineering and millions of dollars in engineering resources at the service of implementing user wishlists. Thousands of suggestions come pouring in from Manifold users on all sorts of things to help guide the product. That process is open to you as well, but if you haven't bothered to send in a suggestion, don't be surprised that

...there does not seem to be any desire...

from anyone else for that thing either! :-)

Manifold doesn't take sides. The company just turns the engineering crank to produce those things that the user community asks for. Along the way that's created a product that in general has many more features than ESRI products do, and those features tend to be implemented with a depth and breadth greater than whatever the equivalent might be in the ESRI line. As I noted in my earlier post, if those features don't include something you think important you will be annoyed, and perhaps if you haven't looked into the many things other folks have gotten into the product you might not even see the breadth and depth that they do. That's OK, it's the way it works, but at least you have a pathway to advocate whatever changes or improvements you prefer.

galvarezhn28 post(s)
#01-Mar-09 20:29

It seems the comparison is based over ArcGIS capabilities. Should be good, base some options of Manifold with extensions, and adding one other column in both sides.

For example if to do some task is needed an extension, in both side could have: IMS, SDE, GIS Server... as like in the Manifold Column, Business tools, Ultimate... etc.

Just for a insignificant additional comparison: The price

gisadvisor
191 post(s)
#04-Mar-09 06:09

I also note that such popup help tips are often moronically trivial: "The Cancel button is used to cancel out of this dialog."

Yes, I am particularly fond of the help advice on: Help on Help under the Control - Common Dialog Control:

http://www.manifold.net/doc/control_common_dialog_control.htm

Show Help for total idiots, who need help on using Help.

I just go to visit that part of the manual when I need a good laugh! Please don't ever get rid of that!!

Dimitri


7,413 post(s)
#04-Mar-09 07:59

I hadn't ever seen that... what a hoot! :-)

Look, I don't disagree that having popup help is good and convenient. Sure it is, when done right. I don't want to give any impression I am against that, just to emphasize I see the question as being about priorities and whether or not it is a better use of the engineering resource than doing something else. The example gisadvisor gives in good humor is actually somewhat related to how these things go in that it is an example of a self-referential thing done for completeness, not so much because it really makes sense. (It is a Microsoft control, by the way, not a Manifold-written control. No idea who wrote that entry but, oddly enough, on rare occasion one sees things like that squeek through the Microsoft process as well as Manifold's.)

Look, when you set out to create something like Manifold and also to document it you have masses of people involved who take on different parts of an overall job involving tens of thousands of modules and millions of lines of code. When you resolve it down to the individual person level each person comes to work every day and deals step by step with what will be his or her many thousands of tasks over the course of a development cycle. You can't have somebody looking over their shoulder telling them every minute of every day "do this" or "do that." It has to be self-guided using some general rules or conventions.

In the case of things like popup Help what happens is that the rule that works best is to tag everything in the GUI. So developers end up putting tags on things like every radio button and other control even if the function of the dang thing is obvious. This can be tedious and distracting from the main work, but it's easier to do it that way. Why? Because unless they have a writer sitting next to them (which would slow things down more for both) it is often quicker and more reliable to tag everything than to undertake the coordination of tagging some things and not others. The writers echo that by putting in at least a stub for everything as well. Since most controls are more or less obvious, the stylistic price of making sure that the non-obvious ones are reliably covered is that you end up with a lot of self-referential obvious popups even when everyone involved understands perfectly well that's what those are. We've all seen this in action in those dumb utilities that are provided by motherboard companies where clearly the instruction was to carpet-bomb the GUI with popups whether or not the popup meant anything.

That's not to say the result could not be considerably improved with an aim towards fewer trivialities and a greater focus on worthwhile commentary when someone with a sense of experience and taste would judge it appropriate. Sure it can. But to do that you are making even greater intrusions into the workflow of a development process, to a degree that can change the pace and tempo to an even greater degree. When people are in the zone and hammering along through thousands of tasks you don't want to tell them to drop this or that to jump back into a totally different thing from eons before, like from last week, to add or remove tags. I'm not saying that's the end of the world or anything, just remarking that it is one of the effects that has an impact on how rapidly a development organization, regardless of size, can respond to evolutionary demands.

My own view on this is that documentation should be focussed on getting it down in some form, however primitive. If you are really working at the leading edge of what is reasonable to do in terms of leveraging technology and focussed on getting the latest and greatest technology into the hands of your users as fast as possible, there is no way documentation can keep up as well as everyone would like. You see that all the time in the really dense parts of Manifold where highly effective engineering can have the greatest impact over the shortest time, those parts which are closest to the internals, that is, the object model. It evolves so fast it has been possible to provide only the barest documentation on what it is. That's been enough for those developers who are truly the point of the spear, so the feeling to date has been that's the right approach, keep the foot on the gas pedal and flow all the investment into where it will have maximum impact (better engineering being prioritized over better documentation). We'll see how that goes in the future.

rfriedman
243 post(s)
#27-Feb-09 09:14

I'll look over the document and provide more feedback later, but I would think that the "Direct Read and Write of Raster Data" refers to data that no import/export/conversion is required to use the data with the software. With ArcGIS this is similar to linking ECW and JP2 images. But, with ArcGIS you can also define tranparent colors in the images, as well as perform operations on the images like those found in Manifold under Image>Adjust and Image>Effects for these image types.

These are all operations that are not available with linked images in Manifold. You should probably remove the X for Manifold in this section, with maybe a "read only" note for JP2, since all other formates require importing the data into Manifold. This is one area where Manifold is definitely lacking when compared to ArcGIS . But on the up side, Manifold's redisplay speed for ECW and JP2 make ArcGIS look like slow ....... dare I say...... OK I'll use the "L" word ..... Leagacy software!

NoCal3 post(s)
#27-Feb-09 12:10

WOOOOW!

Paul68 post(s)
#27-Feb-09 12:55

Under "Tabular Data", Manifold can create statistics, summarize data, simplify field names, and sort by multiple attributes through an SQL Query. I guess there is no wizard for these things, but the functionality is certainly there. Although ArcWhatever is still my main GIS platform, I actually prefer to do stats, summaries, and other table operations in Manifold simply because of this flexibility in SQL.

mdsumner


4,260 post(s)
#27-Feb-09 13:03

Hi tomasfa, you haven't mentioned it so I wonder if you've seen this?

http://ecommons.library.cornell.edu/handle/1813/165


https://github.com/mdsumner

tomasfa
182 post(s)
#28-Feb-09 00:40

I do know about it. Actually I love that document!!

RonHendrickson
283 post(s)
#04-Mar-09 06:37

Tomasfa, would you mind uploading the file in a version less than Excel 2007? My Excel 2003 can't open it, and I don't want to go thru the hassle of downloading and installing a MS compatibility program.

Thanks,

Ron

tomasfa
182 post(s)
#04-Mar-09 21:54

Here it is as requested! Version Word 2003.

Hey guys, after we consider this thread finished. Because I still see some interest and comments on it.

I 'm going to try to add all the observations. If some one, wants to collaborate and maybe add some Manifold only features, they will be welcome and we can get all an improved comparison.

Cheers, Tomas

Attachments:
ArcGISvrsManifold_V2_win03.xls

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.