It was crying out for it.

http://www.spatiallyadjusted.com/2008/06/25/esri-arcgis-93-ships-tomorrow/#comment-34985

nice

Phish reunion - March 6, 7, 8, Hampton, Virginia.

See the serious discussion below Shrek's comments. Did you ever regret installing a new version of Manifold?

Klaus, you're right ! My rule is not to install any ESRI new release before six month pass since I receive it. Even after 5 service pack, ESRI 9.2 is full of bug. Between SP4 and SP5, new bugs have appeared.

With Manifold, I install ASAP new release with confidence.

IMS codes, trainings and programming services available at www.dynamicmaps.net

Where's the beauty in a post like that. Its nice to show people alternatives that they may not have considered, but why do it in the same breath as telling them their existing tool stinks. Plus, there are many things ESRI can do that Manifold as of yet cannot.

I agree with Mike.

Advocating for Manifold is one thing. Insulting someone else's choice of tools is something totally different.

I'm all for increasing the size of the Manifold user community. However, insulting ESRI users isn't going to get us there. It's counterproductive.

While I agree with Nicks premise (64 bit , cuda etc), and if I were an ESRI user I would be scratching my head about their strategic direction, antagonizing the community is counter-productive. Poking fun, you-bet, insulting...not so cool. While too, I think everyone should get their say (and I am very open to devils advocates), the whole Manifold user community is already broadly branded as fanatic.

Having said that, I remember installing new versions of Arc 8.x, what a chore! Manifold? A snap.

Mike, Ralphie,

You obviously disagree with my sentiments, but i am an ogre after all and it is always good to mix it up a little.

But seriously, if a company like ESRI cannot produce a 64-bit version of their flagship product by now then the company is clearly in its death throes and its product does suck because it cannot leverage the potential of even the most basic of modern PCs. To launch their product with such fanfare as if it is the latest and best available is breathtaking, embarassing and hilarious to say the least.

Ask yourself, how long has it been since Microsoft Windoes XP x64 was first made available in beta form to software developers - three or four years? It was for computaionally demanding work like GIS and CAD that 64-bit Windows was needed and created for. If a major software house that supposedly produces the leading GIS sotware cannot get its act together on this, then it is not worth the time of day IMO.

I am certainly do not condemn or despise people who have to use ArcGIS, but i do truely pity them. But sometimes it requires plain speaking to wake people up and point out that there are some very much more economic and better alternatives to the fossil they are using.

The agian perhaps i am also tired at a being looked down on because i dont use ESRI products, snootily by those that do.

I don't disagree with your sentiments at all, Nick. I simply question whether poking a finger into someone's eye is the best way to express them.

I can only imagine ESRI is somewhat panicked about being so far behind the boat in terms of advances in technology.

Nick, I can't criticize give my inability to resist inflammatory language. I don't think it was all that off base but I can see how some would take it as too harsh. I'm trying (... don't laugh, everyone...) not to be so inflammatory myself so maybe we can form a mutual support group to turn over a new leaf, become known for soothing, calm discussion, etc. :-)

Plus, in all fairness to ESRI it really is a big deal to get a major new product out the door so they should be congratulated for that.

It *is* shocking they did not invest what would be a very small effort for them to go 64-bit, but, well, it's their company to run as they see fit, to invest their efforts where they think best. They're not shy about the 64-bit thing either because it is the number one FAQ in the very short "What's New in 9.3" page they have at

http://esri.com/software/arcgis/about/whats-new.html

So obviously they have gotten a lot of questions about this from their user community. Somehow, though, I can't help but think their advanced users expected more from 9.3 in the 64-bit area than a "FAQ you" response.

[OK... OK... a lapse on the "new leaf" front... I'll get better with practise. :-) ].

Without rubbing too much salt into the wound...

It *is* shocking they did not invest what would be a very small effort for them to go 64-bit, but, well, it's their company to run as they see fit, to invest their efforts where they think best. They're not shy about the 64-bit thing either because it is the number one FAQ in the very short "What's New in 9.3" page they have at

http://esri.com/software/arcgis/about/whats-new.html"

I suspect ESRI is nows rather like the latter stages of the Roman Empire - once omnipotent, but now hopelessly over stretched and in terminal decline. May be going 64-bit with its over-diversified product line would be a hugely expensive perhaps impossible task, Fo themn it could be the proverbial straw that would break the camel's back.

"maybe we can form a mutual support group to turn over a new leaf, become known for soothing, calm discussion, etc. :-)"

Flamers Anonymous?

There are ArcGIS users who do understand the score

The agian perhaps i am also tired at a being looked down on because i dont use ESRI products, snootily by those that do.

I can prove this out through an experience. Some municipal officials that I had been trying to sell Manifold and its concepts to began trying to disrespect Manifold during their the process of spending $30K+ on ESRI software and licensing just because most of the Mayor's friends in the state capitol were pressuring him. Because they already had their minds made up and did not want to be confused by the facts, they brought in some GIS "experts" whose agencies have been using ESRI products forever to make a presentation to the Council.

Much to their surprise, the experts (who are friends and acquaintances of mine) started out their presentation by saying that, "... ArcGIS is a dinosaur, and if we did not have to use it, we would not ... and if we were not so fully entrenched in ESRI, we would not use it." They went on to point out much of what we Manifold users already know.

As the above quote of Nick's states, I've been subjected to quite a bit of this sort of thing and am quite tired of it. I can't blame anyone for taking a jab at the competition - it's just the way of things. I wish I could claim that I had more evolved sensibilities, but I don't.

These experts have a task, not only a tool. So you better argue starting from the need for storage of large datasets in DBMSs (Forget to mention PostgreSQL and MySQL, Oracle is fine for a reputationa rubbing off on you), from a flexible design of IMS that can show a 'Theme' (use ESRI terms speeking to ESRI users) in a time convenient for use during internal processes in the intranet, not only to show end products. Resist to say 'Share IMS ... in minutes' because (1st) that would devalue an existing team of people and (2nd) it tends to be incorrect in real life ...

But seriously, if a company like ESRI cannot produce a 64-bit version of their flagship product by now then the company is clearly in its death throes and its product does suck because it cannot leverage the potential of even the most basic of modern PCs.

Who needs 64 bit versions???? Arcview 3.2 is faster than manifold (any version, any update, any anything!). If a software made 10 years ago(??) is faster than something just released yesterday by Manifold...then who needs Cuda? who needs 64 bit???

It is the output from the tools that is important.

Can you substantiate your claim with some numbers?

adam...adam...adam...

just try to open a large shp file (10-20 mb) in arcview & manifold. time the 2 then try to pan the dataset.

the manifold window would "hang" while the arcview window would zip through the move process.

accept the facts adam my boy!

this is the reason why i still keep my arcvie wdongle around the office. just for qc checking of a dataset.

What about the performance of further operations?

How long does it take to render the contents of, say, a 1 MB SHP file? How long does it take to render the contents of a 100 MB SHP file? What about a 1 GB SHP file? When rendering a 100 MB SHP file or a 1 GB SHP file, how long does it take each system to get into a state where the user can start zooming (progressive rendering)? How long does it take to render the screen if you zoom to a subregion or pan in an arbitrary direction, then go back to the previous view?

What about images? How long does it take to render a compressed image? A surface? How long does it take to change the display options for a surface? How long does it take to render an image that is coming from a database? How long does it take to render an image that is in the projection other than that of the window you view the image in (a case of a map in the projection different from that of the image)?

By the way, since your original comment was about 64-bit, I suggest that you measure the performance of a 64-bit version of Manifold.

By the way, since your original comment was about 64-bit, I suggest that you measure the performance of a 64-bit version of Manifold.

oh..64 bit...yeah..ok..oh I get it, it takes a 64 bit system with 8 gb ram running manifold 64 to match the output from arcview 3.2...ok i understand now... thanks for the clarification adam...

Your post above says that noone needs 64-bit because even 64-bit Manifold is slower than ArcView 3.2. Hence the suggestion to make sure that you indeed are using a 64-bit version of Manifold.

huh?? what are you talking about/???

I am talking about the following words of yours:

"Who needs 64 bit versions???? Arcview 3.2 is faster than manifold (any version, any update, any anything!)."

I think everyone feels your pain. Two replies to this character are one too many.

who cares what dataset it is or how big the datasets are. only 1 dataset is really needed for comparison. if it is slow for my dataset then it is slow. period!

it is like buying a car, will you say it is good for speeds above 100kph only? if slower than 100kph then it is not good? it has to be good from 0 to 100 kph because different drivers drive differently.

you can't sell a car saying this is good only if you driver above 100kph ALL THE TIME.

By that logic, Manifold is faster because if you convert a SHP file into a MAP file, I assure you that Manifold will open the MAP file faster than ArcView. That MAP file is another dataset that consists entirely of your data. Manifold opens it faster that ArcView. As you say, period.

adam,

when you import a shp file into manifold and save it...it is automatically converted into a map file right?

so how can you "NOT" convert a shp file to map file upon import?

you are getting mixed up in your own words.

"what a tanggled web we weave when at first we aim to deceive"...was that shakespeare?

when you import a shp file into manifold and save it...it is automatically converted into a map file right?

No.

As Pope remarked, "A little knowledge is a dangerous thing."

no?

oh...care to enlighten a lost soul today?

when does a shp file become a map file most wise one...

show me the light.

Yawn

Just out of interest I've done this. Same data set as a Manifold .Map and exported as a .SHP. Compressed .MAP 65MB. Composite .SHP 220MB. Manifold 8.7 32 bit and Arcview 3.2 on same laptop accessing files from the same place on a public local network drive.

Manifold opening .map 45 secs; rendering full extent 12 secs. Subsequent zoom and pan; sub second.

ArcView add theme to new project 2 secs; Display theme full extent 30 secs. Subsequent zoom and pan; variable but typically 20 - 25 secs regardless of whether a small change of extent or zoom to active theme.

Your observations don't compute it seems, especially concerning interactive use - pan and zoom.

Emilio,

The reason for having 64-bit OSs is that they can address more RAM, not because 64bit faster than 32bit, although there is perhaps an aspect of this.

I doubt there will much performance gain from operning say a 1Gb file on a system with 32bit OS and 3Gb of RAM installed, over doing the same on the same hardware running a 64bit OS. The BIG performanace gain will occur if you have to work with say a 10Gb dataset. To do this on a 32bit system requires creation of temporary files and constant reading and writing to the hardrive(s). Even the fastest HDDs are slow in comparison to read and write operations from RAM. But if you have a 64bit OS you can take advantage of the ability of a 64bit OS to address huge amounts of RAM (some workstation motherboards can hold 128GB!). Then, if you have a suitable motherboard you can then install enough RAM to be able to comfortably hold the entire dataset you are working on in RAM. Then you will see big performance gains.

How long does it take for ArcView to open a 10Gb image (uncompressed ie without using wavelet compression)? Indeed, can it?

CUDA and GP-GPU cards are being used to speed up operations that can be parallelised. Operations on arrayed information especially. So instead of having perhaps 4, 8 or 16 CPU cores performing such operations you could have 250 or 500 or a 1000 GP-GPU cores working on the problem. Then you will see big performance gains. This is why CUDA and GP-GPU computation is making such a big impact in HPC. Operations that previously took weeks can be done in days, those that took days in hours, and those that took hours in seconds or minutes. And this leap, for a few hundred dollars. The technical term for the choice between using CUDA if you can and not taking advantage of it, is a no-brainer!

If you want to see what impact CUDA enable graphics cards are having i suggest you subscribe to Google News and use "CUDA" as the search term.

http://news.google.co.uk/news?hl=en&um=1&resnum=4&q=CUDA&btnG=Search+News

Much of this is beside the point Nick. There are two big ways of improving an application's memory handling. One is to increase the amount of memory it can use, and how quickly it can access it. The second is to reduce the amount of memory it needs.

ArcView 3.x is an excellent piece of engineering in the second sense. It tries very hard not to load anything into memory that it doesn't need to access. That's why it opens a shapefile set (or a set of large images), and renders them at full extent, so astonishingly fast (twice as fast as Manifold, in Graeme's test).

This first impression makes a disproportionately large difference to the user experience, I think. Even though getting any work done on the data, once loaded, is much faster and easier in Manifold than in ArcView.

"There are two big ways of improving an application's memory handling. One is to increase the amount of memory it can use, and how quickly it can access it. The second is to reduce the amount of memory it needs."

I very much agree and i suspect Manifold's strategy is to make improvements on both fronts.

It was late when I did the test comparison above. Just to level the playing field, I saved the Manifold .map as uncompressed - size now 215MB.

Manifold opening uncompressed .map 19 secs, display drawing first time (areas and lines) 13 secs. Total 32 secs.

ArcView select .SHP pretty much instant, display full theme 28 secs. Total 28 secs.

Redisplay once rendered, as previously indicated, instant in Manifold, 20-25 secs each time in ArcView. So yes, ArcView initially opens and displays a largish .SHP polygon somewhat faster than the equivalent uncompressed Manifold .MAP containing the same area objects; a difference of approximately 15% faster for ArcView. After that Manifold is very much faster.

Just to round off, using a 64bit desktop opening the same .MAP but from a shared network folder on the laptop, loads in 19 secs, display drawing first time 6 secs, total 25 secs. If the .MAP is local, 7 secs to load, 6 to display, total 13 secs. Unfortunately cannot supply equivalent for ArcView on same desktop as it won't install on a 64 bit platform, apparently not without tinkering with the registry at least, but presumably it would also perform quicker if so installed.

you guys will never get it!

let me put it this way...

you are trying to build an enzo ferrari (with all the cuda cards, ram, 64 bit, vista os, latest build, etc) when all i am saying is that the model T built in the depression did the same job of running several thousand km.

arcview was able to do the job using less ram, video card, etc and it was written more than a decade ago!

with all the hype around manifold 64 bit, did any of you guys ever stop to think that what you claim as "NEW" and "GREAT" functions was done more than a decade ago?

answering previous posts...you guys say that minfold 64 or 32 is faster than av3.2...say I agree for the sake of argument. you guys have used the latest os, language, card, ram available in the past year and all you could muster up is that is is nearly 2x as fast as av3.2. av3.2 was running on win98/2k at a time when most pc was using only 512 mb ram or even less because of the price of ram then.

if you follow Moore's Law saying that speed should double every 18 months, and av3.2 was released 10 years or so ago then manifold should be 7x faster now than ac3.2?????

did you get my point? if not, then keep on dreaming

as a follow up, i usually visit the esri's arcscripts page. it contains literally hundreds of free scripts covering almost any gis function. you just have to search for it.

for av3 usually you can only use ave or a compiled avx function.

No difference to the Manifold community. You just have to search for it. And more: You'll find people that still develope new solutions for new questions.

You'll find people that still develope new solutions for new questions.

Apparently not the support@manifold.net people. until now you can't even right click a "zoom to selected" function!

if i get it correctly, it is a 4 step process because in the default settings, zoom to selected is not even checked!

Who pays you to do this "emilio.aguinaldo"? It seems like you get deployed about twice a year, for bursts of a week or so - do you do this full time, "researching fanaticism" on other forums?

cuda shuda wuda

md,

no one pays me. sometimes i check on this board and see somethinginteresting to discuss. i said "discuss" .

is there something wrong with bringing legitimate issues for discussion here? ithought this was the purpose of this board.

it seems that when i have you manifold gurus cornered, you then bring up the issue that i am a flamer or spamer (if that is the right term). you can't keep an open discussion? the issue here was speed of manifold right? so what is the problem with my posts? did i say anything offensive? if yes, please point it out in my posts.

i am here for a free flowing discussion.

Cornered? No, I am afraid what is going on is this:

You started by stating that all versions of Manifold are slower than ArcView 3.2. You have been asked to qualify that statement with numbers but failed to do so. You then have been proven wrong by other people who out of their curiosity ventured to do the tests and provided the numbers, then started pretending that this does not matter because Manifold has to be not just faster than ArcView 3.2 but much faster. You also invented an argument about Manifold being inferior to ArcView because you can zoom to a selection in the latter using two clicks. This is where things are now.

I admire your efforts. You seem to be pursuing a really noble aim. I haven't yet fully grasped what that aim is, but I am sure it is something great, something that will really touch the hearts of all. To aid in your aim, I have several suggestions:

First, when discussing the merits of Manifold compared to ArcView try to limit the discussion to exactly one operation. Opening a SHP file is fine. Otherwise you risk being proved wrong on the "ArcView was able to do the job" bit (Manifold can do one or two things ArcView 3.2 still can not do) and on the performance bit (some operations in Manifold are indeed a hundred times faster than their equivalents in ArcView 3.2).

Second, don't be caught out in the wild when someone brings up that you can zoom to a selection in Manifold by selecting the "[Selection]" choice in the Navigation toolbar. That's 2 clicks, like in ArcView. It would probably be a good idea to say that this does not count because this does not work in Manifold 7x. Or, if it works in Manifold 7x, you could say that you meant Manifold 7 or maybe, just to be safe, Manifold 5.5.

Third, strenghen your position on the performance argument by invoking more big names like Moore. You can try using the following variation of Metcalfe's law: the performance should be proportional to the number of users. Or the following variation of Keyne's law: the performance should be proportional to the demand for it. This last one is really great in that you could say that you wanted the performance of Manifold to improve a lot and Manifold has failed to deliver, breaking the law. Everyone knows that breaking the law is bad. Perhaps you could even start a class action suit (!).

Fourth, start creating new arguments. A fine point: when you move from one argument to another, don't forget to say something along the lines of "well, you clearly lost here, I can see that in your eyes, now let's talk about that other thing...". I realize you might be busy doing all the other items but it is crucial that you don't forget this last bit of advice. Solidifies your position.

Good luck!

Nice Adam (he heh )

Then again that other law could be thrown at us:

A man convinced against his will is of the same opinion still

Us Manifolders can be like that as opposed to other more objective commentators.

We are quite happy in our delusions.

"You started by stating that all versions of Manifold are slower than ArcView 3.2"

You have been asked to qualify that statement with numbers but failed to do so.

I don't need to qualify, another manifold user already did it for me. Just read the posts above.

First, when discussing the merits of Manifold compared to ArcView try to limit the discussion to exactly one operation. Opening a SHP file is fine.

Again another manifold user did the measuring for me.

Second, don't be caught out in the wild when someone brings up that you can zoom to a selection in Manifold by selecting the "[Selection]" choice in the Navigation toolbar. That's 2 clicks, like in ArcView. It would probably be a good idea to say that this does not count because this does not work in Manifold 7x. Or, if it works in Manifold 7x, you could say that you meant Manifold 7 or maybe, just to be safe, Manifold 5.5.

No. You measure the steps from start up to the point when the output is the same for both system. If manifold does it in 5 steps then it is 5 steps to the desired output.

Third, strenghen your position on the performance argument by invoking more big names like Moore.

We are talking of speed here...Moore's Law is about processing speed. Sorry but I never heard of keyne or metcalfe and i think majority of user's here never even heard of those laws. you know there are several thousand laws of physics written in books that most people never even opened. but you know of newton's law, you know of einstein's law. point being you do't have to look for obscure law to proove your point. anyone can go to the library and look for a law that no one's ever heard of and say that this proove's my point!

Fourth, start creating new arguments. A fine point: when you move from one argument to another, don't forget to say something along the lines of "well, you clearly lost here, I can see that in your eyes, now let's talk about that other thing...".

i would like to believe that i won my cases, because i got you guys riled up. there is a quote that goes...

if you cannot beat someone in a civilised manner then you get angry...and call him names and ridicule him...so to distract from the real point...

Nice! You mean that "instant in Manifold" may be slower that "20-25 secs in ArcView". Masterful! I didn't see that at first, I admit.

Moore's Law is about processing speed

and

you do't have to look for obscure law to proove your point

Are you kidding? You should at least go to the library to ensure the law you are using means what you think it does. Moores Law is about transistor counts on microchips. There is a loose correlation between between transistor count and speed, but to state it's about ptocessing speed simply displays another facet of your ignorance.

I don't need to qualify, another manifold user already did it for me

and

i would like to believe that i won my cases

You are the only one who believes it. The facts presented for you by others actually defeated your case.

Could you bring back andres.bonifacio? He was a bit easier to deal with.

Will Render (for?) Food

ignorance???

processors rely on semiconductor componenrs to compute calcualtions from softwares. if you increase the number of these components IN A PROCESSOR then the processing burden gets spread out and thus the computation will get done faster. if something gets done faster then it has to do with "SPEED".

you know fast or slow = speed = distance/time...you know the simple formula...

you guys keep on saying that i lost my cases but i have yet to see you present any numbers...

you keep on asking numbers from me and yet you say i lost without even presenting your numbers!

you keep on blabbing about obscure laws and about my ignorance with regards to moore's law etc and yet "SHOW ME THE NUMBERS!!!"

Emilio, your current threads relate to speed of initial display. You obviously(?) could have supplied similar NUMBERS to the ones I've posted, but you didn't. The forum aims to be helpful and informative, so we all chip in if we have the time and ability. From our limited tests, you can take satisfaction that your "case" for "time for initial display" is correct.

Where does that leave us?

Most of us will want to do some productive work, otherwise we wouldn't, typically, be reading this forum. We use Manifold because it allows us, overall, to do such tasks effectively and efficiently, including overall rendering time. Taken over even a small task, 20-25 secs to re-render a view in AV when we "zoom to selection" for example, is obviously less efficient than effectively "instant in Manifold". Compound it in a typical workflow, that would equate to a large block of dead time.

Of course if we deploy these technologies simply to look at an interesting display, we'd all have lots of dead time on our hands to find something useful to do with an idle finger!

Best of luck with whatever it is you're doing.

You are somewhat outnumbered so if you are trying to show off your stamina I would say you are at a disadvantage. And if that thread grows too large, I don't think Nick will care too much if it will vanish into the hidden spam section.

The numbers are "instant" and "20-25 seconds". For details, scroll up a few inches.

I don't think Nick will care too much if it will vanish into the hidden spam section.

Aw! And, just when it was getting interesting...

ignorance???

Yes. I think that's what science-oriented people find offensive about people who babble on about technical matters who don't know what they are talking about and get things exactly backwards. The mental imprecision is just a bad aesthetic. For instance...

processors rely on semiconductor componenrs to compute calcualtions from softwares. if you increase the number of these components IN A PROCESSOR then the processing burden gets spread out and thus the computation will get done faster.

No. The above is grossly wrong, almost exactly backward of the true effect. I don't think it will make a dent on you, but for the education of other folks who may be interested in Moore's law, why it operated and why it failed, the situation is very different from what you describe above.

The classic speed pickup from Moore's law did not arise from having more components, it came from smaller components. Smaller components are faster for a variety of reasons.. You do get some slight pickup from having more components because you can implement more complex tricks such as looking ahead into the instruction stream but that is not proportional to the size/number and it is a gain that was quickly lost by the disadvantages of having more components such as not being able to get rid of all the heat they produce and not being able to synchronize ever more complex functional units with each other every clock cycle.

Interested readers can see more (...almost wrote "Moore"...) discussion at: http://www.manifold.net/video/Supercomputer_GIS.wmv

Ah, and speaking of ferocious ignorance...

you know of newton's law, you know of einstein's law.

No. It is exactly the opposite, as the essence of both Einstein's special and general theories is exactly that they are non-Newtonian and you cannot derive them from Newtonian physics. It is a tribute to Einstein's special genius and extraordinary creativity that he came up with not one but two (actually, three, if you count his explanation of the photoelectric effect) theories which are completely fresh and totally different from Newtonian physics. [It never fails to amaze me how people who apparently have absolutely zero knowledge of physics cannot resist reaching for physics examples.]

Can't resist chiming in a bit on ArcView 3.x:

ArcView 3.x is a fine bit of kit for its day. ESRI trotted it out when they were getting their heads kicked in by a more agile competitor, MapInfo, and they did a good thing.

When both products are operated as instructed, Manifold is significantly faster than ArcView 3.x, just as today's iPod is a dramatically better and more convenient music player than the cassette-based Sony Walkman that was the "iPod" of ArcView's day. But just as no one would suggest that an iPod user give up the conveniences of 2008 in order to construct some artificial comparison to the technology of a bygone day, it's kind of dumb to suggest that one should compare Manifold to ArcView by refusing to use today's technology.

Even if you want restrict the comparison to obsolete 32-bit technology only, Manifold is faster in your actual working life than ArcView and with the sole exception of a slight lead for ArcView in an initial project open is always faster. If you choose to use today's 64-bit technology (instead of artificially restricting the comparison to long obsolete 32-bit technology), Manifold is significantly faster than ArcView all the time while doing a whole heck of a lot more to boot.

But, if anyone disagrees with that they can go buy a copy of ArcView on eBay or craigslist and have at it! :-)

The classic speed pickup from Moore's law did not arise from having more components, it came from smaller components. Smaller components are faster for a variety of reasons.. You do get some slight pickup from having more components because you can implement more complex tricks ...

That's basically what I meant by the loose correlation but didn't want to to smack my head against the wall that is emilio for that long!

Will Render (for?) Food

Why do we keep rising to the bait offered by this clown? This is all very reminiscent of the pointless arguments I used to have on the school bus twenty something years ago about whether the Commodore 64 was better than the Spectrum 48K!

If Emilio was genuinely interested in having a discussion, he would loose the confrontational attitude and simply ask the question as everyone else has the courtesy to do on this forum. As it is he is wasting the time of many good and helpful people by being deliberately antagonistic.

We've all been sucked in before by this guy and it was really boring to listen to his one dimensional arguments then.

Spectrum was better of course and Sinclare a genious.

Agreed, but the 64 was ahead of its time

I can nearly remember some BIOS calls for our C64, such as the JSR that would magically place a character at a given row and column on the screen (rocket science!—faster than using ANSI control codes). Ferreting these out (using debug -d, or am I getting confused?) was fun. Then manually writing the byte values for 6502 machine code into string arrays at the start of each BASIC programme. Can't remember how it was loaded and called from BASIC though. Haven't thought about that for a while! No wonder I turned out like this.

you launched a machine code program from C64 basic with a SYS (system) call. i.e SYS64738 to reset the machine.

Yes! How funny. Now I remember. Running a machine code routine from within BASIC involved writing the byte code from the string array into the unused video memory starting at... (can't remember) then launching a SYS to execute it there.

(Sounds a bit like caveman CUDA now.)

If Emilio was genuinely interested in having a discussion, he would loose the confrontational attitude and simply ask the question as everyone else has the courtesy to do on this forum.

i was goingover my posts and could not find where i was being confrontational? it was one of you guys who started the controntational attitude --->dmbrubac...ignorance comment??

but i guess it is useless, you guys cannot have an open discussion when confronted with the abilities of other products...especially obsolete products that can still compare your latest releases...

I guess so ... bye.

So this guy is arguing that ArcView is better because it's initial load speeds are better? There's always technical tradeoffs made. The Java HotSpot VM, for instance, will scan the bytecode it runs for frequently accessed code loops and convert these sections of code to native machine code. I'm sure the .NET CLR does something similar. This initially requires more startup time than a regular VM, which languages like Python and Ruby use, but yields code that's 20-30x faster in the long-run. The benefit with Manifold is that you only have to endure the file loading stage once and subsequent operations are fairly quick.

The funny part about this whole discussion is it's kind like arguing the performance aspects of the Kia Sophia vs. a Daewoo Lanos when you've got systems like PostGIS which can efficiently deal directly with datasets sizes of which ArcGIS and Manifold wouldn't have a prayer of touching, for free, fast, and in less memory space. It just comes down to partitioning the data for consumption by the CPU correctly, something the PostGIS team has already conquered with very little actual personell. You don't need gobs and gobs and gobs of memory as every task conceivable in a computer can be partitioned and parallelized. Methods for doing this have been researched and publically documented ad nauseum so there is really no excuse for the lack of full implementation of these algorithms in software packages today. Once the groundwork for this has been laid, these data segments for these operations can be easily shipped across the network to other computers, a local multi-processor GPU, or even just the local CPU.

Yes, true, PostGIS does not have a really good GUI that aids in productivity, but that's just because nobody has created one. There's no reason why you couldn't, for instance, write a Manifold-like GUI application that basically keeps a connection open to PostGIS and performs all of it's operations by issuing SQL statements to the underlying backend. Anyways, you get the point, I'll stop rambling on...

Need industrial grade Manifold hosting? Scaling, Load Balancing, Special Tuning, etc. Drop me a line.

Why would you want to write a new, seperate GUI for PostGIS when you could request a Database console in Manifold not only programmable through UI-Scripting? You would have all the import/export options and manifolds GIS functions, many times more than those of PostGIS.

systems like PostGIS which can efficiently deal directly with datasets sizes of which ArcGIS and Manifold wouldn't have a prayer of touching, for free, fast, and in less memory space. It just comes down to partitioning the data for consumption by the CPU correctly, something the PostGIS team has already conquered with very little actual personell.

I happen to like PostGIS and in general the company agrees with you, as can be seen from Manifold's use of spatial DBMS for things like storage of massive images. It's been Manifold policy for some time to advise users the way to fast, fast, fast performance with really large images is to store them in DBMS. That got started with georasters in Oracle with 7/7x and one reason 8 extended Manifold's spatial DBMS capabilities to "generic" storage was to make it possible for folks to do this with whatever DBMS they like, including specific support for things like PostGIS.

But for all that there is the indisputable reality that access between a processor and memory takes microseconds while access to disk takes one thousand times longer, milliseconds. No matter how much you might parallelize data storage you still have to get that data off disk and into a very tightly coupled processor/RAM arena to do things with that data. So in addition to very good DBMS storage you also need the other side of the coin, which is very good processing architecture.

There's no reason why you couldn't, for instance, write a Manifold-like GUI application that basically keeps a connection open to PostGIS and performs all of it's operations by issuing SQL statements to the underlying backend

Yes, you could do that but then you'd be returning to time-sharing where thin GUI clients sitting on the desktop launch SQL back at the server, where all the processing and spatial computation happen. All the users will be time-sharing what few processors are on the server. Compare that to doing the computation on your desktop with data fetched from the DBMS "file cabinet", where you could have very many processors on your desktop all devoted to one user... no time sharing. 100 processors per user are far faster than 100 users per processor. I don't disagree about the value of data centralization, but I think it is more performant to centralize data but to distribute processing.

Consider a real-world scenario like the CUDA demo on the News page of the manifold.net web site. The time required for the task is not dominated by the time required to fetch data, it is computation. Even if you rigged up the server with CUDA devices, you'd still be time-sharing those among all the users of that server. Much better for each user to have hundreds of processors dedicated to him alone for his computation.

If you compare a traditional RDBMS vs. a GIS database, the disk fades far into the background as a bottleneck. I think it's fair to say that we're still at a point with most GIS operations that after significant optimization, the CPU will end up always being the bottleneck. Yes, you can load everything into memory, and that's a really easy brute force method to make data readily available for the CPU to crunch, but if the disk and memory resources are used intelligently, the end result is a system that can be distributed among multiple processors and will scale to near-infinite datasets. Yes, you could, for instance, load a 32GB table into memory and use sequential scans to scan it all pretty damn fast, but a table on disk with a btree index will blow it away for looking up chunks of data that you need to work with. I'm not saying intersecting a 16GB polygon with a 16GB polygon is the same type of operation, but you CAN apply a MapReduce-like process of partitioning the data into sets, iterating the set performing your needed operation, and producing a tiny end result to this type of operation.

To be honest, as much as I brag on PostGIS, it really hasn't gotten quite to THAT point because the smallest unit it will deal with is what you've got in a single row's geometry column, but at least when you decompose a polygon into multiple rows, PostGIS will seemingly take advantage of this much more readily than Manifold will as Manifold will eventually run out of physical memory and start using swap, which is "game over" for any big operations performance-wise. After studying the PostGIS source, it really only needs the rows of geometry data it's working on at that point in time in memory and the CPU will lag far behind the disk I/O speed, especially when you start dealing with complex objects. I think when the PostgreSQL team finally builds a strong internal framework for performing large DB operations over multiple threads, we'll see this proliferate into the PostGIS side of things. Unfortunately, the demand on the PostgreSQL side is not high because typically single queries that utilize "big data" are ran in data warehouses which are not particularly CPU-performance sensitive. The task of re-engineering the internals of PG to work in a real multi-threaded environment are somewhat daunting. From the other end, PostGIS itself COULD be engineered to create a pool of worker threads that could perform some operations in parallel. I've got some VERY experimental patch code sitting on a box here that does something like this for point-in-polygon. Creating balanced sets of data for GIS operations is somewhat hellacious.

As far as doing the work on the client-side, I totally see where you're coming from. I'm not advocating centralizing the processing itself, but you could, for instance, have a centralized store and replicate data to each desktop either continuously or on-demand. Since the base store is directly compatible, all of the infrastructure resources for PG (Slony, PITR shipping, etc) could be utilized for these types of operations. Each desktop would have it's own PostgreSQL/PostGIS installation. This is all theoretical and I'm not saying this is a superior way of doing things, but illustrating a method of building a GIS environment on-top of optimized, available resources.

Need industrial grade Manifold hosting? Scaling, Load Balancing, Special Tuning, etc. Drop me a line.

oh...wise one...you have shed light on this humble subject...

thank you for gracing your valuable time and energy to enlighten this lost soul...oh...ah...

but it was all jumbo lingo.

It is exactly the opposite, as the essence of both Einstein's special and general theories is exactly that they are non-Newtonian and you cannot derive them from Newtonian physics. It is a tribute to Einstein's special genius and extraordinary creativity that he came up with not one but two (actually, three, if you count his explanation of the photoelectric effect) theories which are completely fresh and totally different from Newtonian physics. [It never fails to amaze me how people who apparently have absolutely zero knowledge of physics cannot resist reaching for physics examples.]

in the above paragraph, it was full of nouns,adjectives - i.e. special genius, extraordinary creaivity,fresh & totally different, non-newtonian & totally different from newtonian physics...

when first read, it sounds impressive...but when i tried to analyze it ... it really has no sense! it sounds like someone who as zero knowledge of physics cannot resist reaching for physics examples.

it's kind of dumb to suggest that one should compare Manifold to ArcView by refusing to use today's technology.

i was comparing your top of the line today manifold's capabilities that you so much exclaim as God's gift to humanity (at only $245!) can also be achieved by the AV3.2 released 10 years ago!

Even if you want restrict the comparison to obsolete 32-bit technology only

so now you have given up the comparison of manifold 32 to av3.2? what you are saying now is there is no comparison between av3.2 and manifold 64 because av3.2 was not written for 64bit systems?

ok...that is a white flag if i ever saw one...thanks

when first read, it sounds impressive...but when i tried to analyze it ... it really has no sense!

Yes, he tried as best as he could. That's emilios personal problem and I'm so sorry for him there is no medicine. He should better take care his customers never reveal who's the guy behind this nicename.

yeah right.

klausDE and Dmitri...reminds me of people that i hired in the past.

after the completion of a project...when we have written all the pertinent reports & graphs, etc for out final and interim reports and the thickness of our reports are less than 2.54cm thick, we would call these types of 'intellectuals'.

their primary job really is to read the final reports and add lines of really non-sense but nice sounding sentences in between our reports. just so that it would look thicker. sometimes a 1 volume report can become 2 or 3 times thicker.

i think you should send me your email addresses and fees for such types of jobs. don't worry i think i can afford your fees. you don't have anything to do i guess because you keep on replying to my posts.

me, i can afford to because I CAN.

Sorry, beyond price. I use to work only in result-oriented teams with willlingness to listen accepted as a common and basic cultural technic.

Now that is what I was talking about. That is what I need. A simple NO would have suffice but you were able to extend it to 24 words!

wow. let me know if you change your mind.

emilio ..... or who ever you are, you should to take your own advice, the above post could have been much shorter. Were you capitan of the debate team .... that always lost, but thought they won?

Emilio, there was a lot of software sold 10 years ago that was "faster" than what's on the market today. That's because it had far fewer capabilities than the software sold today.

10 years ago, the "new" operating system on everyone's desktop was Windows 98.

If that's where you want to be frozen in time, God bless you. I have a shoebox of old CD's I'll sell you cheap. Myself, I want something more modern. It helps me get my work done.

You should use whatever gets YOUR work done. If that's ArcView 3.2, more power to you. Just don't bother me with it.

In forum spirit; have your drawing in a map component, right click the drawing's tab, and hit the "s" on the keyboard, assumes you have something selected. If you have several things selected, use the info pane with filter depressed. That will allow you to zoom to / center sequentially through selected objects.

graeme,

to put a drawing in map would take at least 3 steps, add to that the 2 steps that you mentioned.

anything faster?

av -> right click> zoom to selected....2 clicks

Adding a theme to a view in AV also requires a few steps. It's analogous to adding a drawing to a map component in Manifold.

Manifold > right click > "s" (not case sensitive by the way) zoom to selected, one click and a finger!

sorry graeme,

to add a theme is analogous to adding a drawing in manifold. therefore it cancels each other out. after this you have t o make a map--> add the drawing-->open the table-->select the feature-->go back to the map-->right click "s"

i rest my case.

with regards to moore's law, 2x speed every 18 months would result in an exponential function.

therefore manifold's speed should be more than 7x that of av3.2!!!

sorry i am weak in the math department.

Emilio,

Just for context, are you still using Manifold 6.0 as the basis for your positions?

ver 6? NO off course not...

i recently got v 5.5 from half.com

it runs fairly well and is quite cheap.

Well, unbelievably, I actually learned something really useful from this thread.

"Second, don't be caught out in the wild when someone brings up that you can zoom to a selection in Manifold by selecting the "[Selection]" choice in the Navigation toolbar. That's 2 clicks, like in ArcView."

It has always bugged me there was no way to zoom selection other than in a map, now I know better. Another useful tool in Manifold that was always there, just cunningly hidden.

Actually, while testing what you discovered Mike, I found a way to do it in one click. Have the info pane available and when an object is selected, just click once on the zoom button. Hey presto!!

"av -> right click> zoom to selected....2 clicks"

These steps are forArcMap (whatever license level, Arcview, ArcEditor or Arc/INFO).

Av3.x - there is no right-click. Can click zoom to selected button or menu item.

AV3 and Arcview level ArcMap is being confused here.

Cheers

A hack for those of us that still have an ArcView 3.x licence floating around to access archaic projects:

You can't install AV3 in XP64 but it runs under XP64 . It's only the installer (16bit peace) that wouldn't run.

So you have to copy an existing x32 installation of AV3 (...\ESRI\...) and all of the ESRI fonts to the new x64 system and export/import the registry tree. As AV3 never learned to respect modern windows use of the program folder (8+.3 file names, no SPACE allowed) it's likely that you can recreate the same directory structure. In case AV3 wouldn't find it's DLLs you have to register them. Find more infos from Thomas Mitchelland a link for german users.

Good stuff Nick about time we had another flamewar over there, been a bit boring lately

Caution: For more sensitive users please don't go to that thread it could get a bit ugly.

Chat with Manifold users on IRC Server: irc.freenode.net, Channel: #planetmanifold, IRC FAQ

Good stuff Nick about time we had another flamewar over there, been a bit boring lately

BC ...:-) you miss me...you really miss me??

I just can't find the words to express my feelings of your return, so I'll let the great Charles Dickens express them:

“The man who knows only one subject is almost as tiresome as the man who knows no subject.”

Chat with Manifold users on IRC Server: irc.freenode.net, Channel: #planetmanifold, IRC FAQ

It’s one thing to support leading edge technology, and another to support the needs of an industry. So ESRI isn’t 64 bit compliant and does not support CUDA technology? There are multitudes of GIS industry functions that ESRI does support and Manifold does not. The fact is, until Manifold supports these functions, many of them being basic needs of GIS users, this argument and those trying to make it are going to be considered fanatical.

Comparing a basic GIS need such as spatial object creation, ESRI and Manifold are not even in the same class. ESRI supports both straight line and curved sections, Manifold does not. ESRI’s data frame can be rotated, especially helpful in creating squared features such as building footprints, which cannot be done in Manifold. The ESRI sketch allows one to create features that are parallel or perpendicular to other features. It also allows one to switch tools while creating the sketch, allowing one to create a feature and edit it at the same time. The trace tool allows one to trace other features and also apply an offset from the feature, and there are many other tools for creating features such as the distance-direction and distance-distance tools. These are functions that are nonexistent in Manifold. Even many of the shared functions between the two programs are performed much more efficiently by ESRI, auto completing polygons for example. Obviously the group at Manifold is very capable, so if they refocused on the basics, and addressed many of the weaknesses of the software, then people could have a serious discussion about organizations replacing ESRI software with Manifold.

Good points. Not all of them totally correct (see COGO for an existing distance-direction function) or driven by ESRI workflow instead of Manifold workflow (rotate the building footprint instead of the frame) - but all of them worth a feature request.

And I agree, the CUDA hype gets boring. Though I'm quicker in Manifold than in ArcGIS 9.2 (I have to use both) and though I'm one of the limited number of surface users, I'm sure I would benefit more from more intelligence in automatic labeling, the long awaited expansion of paper-oriented layouts with a full-featured graphics editor and more edit tools.

And I agree, the CUDA hype gets boring. ... I'm sure I would benefit more from more intelligence in automatic labeling, the long awaited expansion of paper-oriented layouts with a full-featured graphics editor and more edit tools.

Words of wisdom! I totally agree with you.

"And I agree, the CUDA hype gets boring."

This reminds me of people who questioned the need to develop 64-bit operating systems and the memory they can address. Parallelisation, GP-GPUs, CUDA and Open-CL are the future, and will enable things that a few years ago that would have been impossible on a desktop computer. GIS users can either recognise the potential of the new technologies or they will become marginalised by those that do. These new technologies are as sure as day follows night going to change the nature of working with geographic information and the what has hitherto benn considerd to be "GIS work".

Yes I agree with some of what teconner says. Our other GIS system in use corporately is Cadcorp. As much as I like Manifold for some of the amazing things you can do with SQL for example, Cadcorp is far superior for digitising (which is why most of the large digitising firms in the UK use Cadcorp). Manifold does need to get some digitising basics sorted out (features which I have previously requested). For instance, toggling segment snap on and off during the digitising process, digitising tool transparency so you can switch map layers on and off mid-process whilst digitising features, drawing a line parallel to another line (or tracing a feature with an offset applied), drawing a line perpendicular to another line, snapping to a line's midpoint, drawing in orthoganal mode. Also whilst editing features I would like to be able to draw a box around several vertices and delete them all in one hit, not have to select and delete them one at a time.

CUDA's good (or it will be when it applies to vector drawing and operations) but I agree that there are a few basics that need sorting. If the engineering team can get CUDA working, it can't be that hard to get some of these basic features in place (can it??)

That's a great list James. (I read it as corporately as I could, shoulders back etc.) Especially the last point, though maybe it needs to be worked out a bit more. Once we enter edit mode (Ctrl-Alt-click), should edit handles become selectable, just as objects are normally? This is (nearly) what you suggest, and I think it would be fantastic, opening a wealth of possibilities. Use any of the selection tools on them, then delete the selected coordinates, or reposition them, as a group. One other point: you left out snapping to intersections, which I think you'd probably want to include in your list.

The other massively useful thing would be a right angles digitising mode, so at each mouse click during digitising of a line or polygon, the new segment is at right angles to the previous. Particularly useful for capturing rectangular or square buildings would be say a right-click (finish digitising) function perhaps modified with Ctrl key, which works out the placement of the last vertex for you, so that all internal angles in a digitised building are indeed right angles.

I did a simple digitizing 'helper' for someone a few years ago and then promptly forgot about it. Also, I've been assembling a bunch of utilities together (currently about 25) for a while now, but back-burnered because of a big project, that I planned on selling for $25 to $150 each, depending on complexity of course. This one is certainly at the $25 end!

I could add that tool to the list if there's a market...

You can set the axis lock multiple (e.g. 30, 45, 90), 'flick' the lock on and off for odd shapes and have it automatically adjust on closure.

The only problem is I have good reason to wait a few months before 'productising' it. Waiting should simplify the tool and improve the workflow.

I have tools that address a number of the other items you write about too.

Will Render (for?) Food

Selections and edit handles: seriously, that occurred to me in passing the other day. Not sure what the context was, but something like wanting to move en masse most of an object's coordinates while leaving the rest. I think it implies a new "set" of selections, or maybe just a stripped down version of selections now - since selections are part of the database table structure used by drawings for objects. I guess that you could have mini-selections, perhaps that apply only to the table of coordinates that make up an object - effectively you would have a Selection (I) column added to every object's X/Y table of coordinates - so any given object would keep track of its own selection within that table.

cuda shuda wuda

Thanks to you and others for all the wonderful suggestions! Many of them will surely make it into future versions of Manifold.

I would suggest that the reason CUDA might seem overhyped relative to the "basics" is that while moving all operations to CUDA is a huge but still finite task, you can never really say you are finished with the "basics". What does and what does not constitute the "basics" varies from person to person and also from year to year. In fact I would suggest that there are some people who consider native 64-bit operation and support for GPGPU technologies to be "basics" already and the number of such people will grow significantly in the coming years. So, since CUDA is a subset of "basics", it creates more opportunities for hype, because being honest people we refuse to hype something we don't have or won't have soon enough.

Gets me right into Flamers Anonymous, I guess...

I guess we'd better continue this discussion of feature requests in a new thread (and parallel prepare feature requests directed to sales@manifold.net) so they don't get lost.

I personally already have voted for a couple of ideas but have not thought of this nice multiselection of edit handles.

Techconner,

Your make some valid points, but if a software house cannot keep up with the latest operating system programing and hardware technology advances then all that will happen is that they will continue to devlop a product that will be increasingly confined to being run on increasingly obsolete hardware.

You list features that ESRI products provide, some of these you may be right in that Manifold should have (but have you suggested them?). But i suspect that often ESRI products provide one-step tools to do a job that in Manifold can be completed in several steps.

But should Manifold GIS aim to be a low-cost clone of and replacement for ESRI products. I dont believe it should. There are many things that ESRI products cannot do, which Manifold could provide, especially since its commitment to parallelisation and 64-bit operating systems with the advantages both bring. From a commercial perspective it is better to differentiate yourself from the competition by providing in your product things that the competition does not or cannot provide, rather than simply providing what they do, even at a lower price.

Techconner,

Your make some valid points, but if a software house cannot keep up with the latest operating system programing and hardware technology advances then all that will happen is that they will continue to devlop a product that will be increasingly confined to being run on increasingly obsolete hardware.

You list features that ESRI products provide, some of these you may be right in that Manifold should have (but have you suggested them?). But i suspect that often ESRI products provide one-step tools to do a job that in Manifold can be completed in several steps.

But should Manifold GIS aim to be a low-cost clone of and replacement for ESRI products. I dont believe it should. There are many things that ESRI products cannot do, which Manifold could provide, especially since its commitment to parallelisation and 64-bit operating systems with the advantages both bring. From a commercial perspective it is better to differentiate yourself from the competition by providing in your product things that the competition does not or cannot provide, rather than simply providing what they do, even at a lower price.

Personally, I don't care what ESRI chooses to do with their product line. I use ESRI software because the company I work for buys it and I am paid to use it. Overall, I think they have some good products, but pricing is the prohibitive factor in my personal use of their products.

I am a Manifold customer so I do have a personal interest in the development of Manifold. I never made the claim that Manifold should be a low-cost clone for ESRI products, but Manifold should be able to perform the most common GIS functions. What I do want is for Manifold to be far better than ArcGIS.

When Manifold can satisfy most organizational GIS needs without relying on the use of other GIS software to perform certain tasks that it cannot do, then Manifold will be taken very seriously by the entire GIS community. Manifold has a lot to improve on, and I think they are on the right path. The increase in performance from 7 to 8 demonstrates this, but there is still a long way to go to be the best GIS software.

"I never made the claim that Manifold should be a low-cost clone for ESRI products, but Manifold should be able to perform the most common GIS functions. What I do want is for Manifold to be far better than ArcGIS."

Ok point taken, but Manifold is usually compared to ESRI products for rightly or wrongly. I just wanted to make the point that ESRI products should not be considered the acme of what other GISs should be aspiring to surpass and for this reason users should not simply put forward devlopment suggestions based of making this comparison. I understand why they do so, but there is a far broader range of ideas and algrithms to to available than those that have been incorporated into ESRI products.

Minor note - while I agree that Manifold's COGO needs improvement, I would use the same argument to point out that ESRI's spatial feature creation is (personal opinion here) quite lacking when compared to something like Autodesk's COGO. Many of those that I work with/for will design/create/draw in Autodesk and then port the information over to either Manifold or ESRI.

So, I would hope that (as far as COGO is concerned) Manifold focuses on making their tools more in line with the popular CAD based applications, and not other GIS applications.

As for efficiency, that would be a matter of opinion wouldn't it? On the whole we've been far more efficient using Manifold then we ever were w/ ESRI (yes - we knew how to use it).

Just an observation.

---------- JBurn patience - just need a little more ...

Manifold users have to be honest with themselves though. We can talk all day about multi-threading and CUDA but in reality (using massive broad brushing and empirical evidence), most Manifold users won't really see the benefit here. How often has your CPU usage really jumped above a single core in your day-to-day? At the same time, the 64-bit support is well implemented, but only useful for those operating with large datasets. In reality, the 64-bit support seems like an easy patch for what should be better atomization and breakdown of operations so they can spread across multiple processors and kept on disk instead of guzzling RAM needlessly. PostGIS seems fine doing the same operations as Manifold operating within 512MB of work memory (read: 32-bit memory space) on much larger datasets. Manifold has to load all of the data it's dealing with into memory at once so you NEED 64-bit and a TON of memory. GIS operations are such that you're more limited by local cache speed and processor power than bulk I/O as loading/unloading is very rarely a bottleneck. However, from a marketing perspective it isn't so great to build things to run this way, as the most performant path can't always be reduced to flashy buzzwords like 64-bit and CUDA. I'm not saying ArcGIS is better or faster in these ways, actually it's probably the contrary as trying to beat ESRI products at performance is kind of like running in the special olympics.

Using the price as an excuse is also not valid. To a professional, the difference in cost between ESRI and Manifold products isn't high enough to make a difference. For high performance professionals, it's not worth their time to mess around with things that aren't hands-down the best or that needlessly waste their time. The same argument is used by the Manifold team against open source competitors. Open source, in general, has come to realize that it doesn't matter how free their products are, if they don't compete with and exceed the commercial products, even on what may seem like insignificant features, they'll never even gain a 2% market share. Although this has been less of an issue within the last few years, many Internet startups who initially built their code on MySQL realized why all of the big guys were using Oracle and SQL Server after they tried to scale past one server. The popular open source projects are the ones that blow the commercial ones out of the water.

I'm really hoping all the performance issues are resolved as promised in the next major release though. I understand the challenges of building fast software and comprimising code time between performance and features, but when the Manifold team is out evangelizing on the blogosphere using all these buzzwords, they bring the criticism upon themselves. It's easier to forgive faults when the one at fault isn't looking down upon others as if they are inferior.

Need industrial grade Manifold hosting? Scaling, Load Balancing, Special Tuning, etc. Drop me a line.

"Manifold users have to be honest with themselves though. We can talk all day about multi-threading and CUDA but in reality (using massive broad brushing and empirical evidence), most Manifold users won't really see the benefit here."

I disagree. I think this is a very mistaken analysis of the requirements of Manifold users and potential Manifold users now and in the future and even more so of the needs of those more widely who need to create, analyse and visualise geographic information in its broadest sense (ie any and all information with geospatial context). You are basing your views on a tiny subset of the those who work with a tiny subset of geographic information (ie users of GISs as they are now) and a limited appreciation of the diversity and breadth of geographic information."At the same time, the 64-bit support is well implemented, but only useful for those operating with large datasets. In reality, the 64-bit support seems like an easy patch for what should be better atomization and breakdown of operations so they can spread across multiple processors and kept on disk instead of guzzling RAM needlessly."

Whatevcer your views on 64-bit OSs, all OSs will be 64-bit very shortly. I suspect Manifold will only available for 64-bit OSs in the not too distant future. "Using the price as an excuse is also not valid. To a professional, the difference in cost between ESRI and Manifold products isn't high enough to make a difference."

This is absurd. Any company that does not keep its running cost to a minimum, for example by purchasing $40K/license software when they can get alternatives for a few hundred dollars, is heading for the scrap heap. Havent you heard, there is a global recession, money is short."For high performance professionals, it's not worth their time to mess around with things that aren't hands-down the best or that needlessly waste their time."

Exactly, that is why i believe Manifold.net should aim high, and strive to be the most advanced and capable tool for the processing analysis and visualisation of geographic information available for this sector of those who work with GI Given the background of the Company and recent technological developments, i think they can achieve this.

But should Manifold GIS aim to be a low-cost clone of and replacement for ESRI products. I dont believe it should. There are many things that ESRI products cannot do, which Manifold could provide, especially since its commitment to parallelisation and 64-bit operating systems with the advantages both bring. From a commercial perspective it is better to differentiate yourself from the competition by providing in your product things that the competition does not or cannot provide, rather than simply providing what they do, even at a lower price.

I disagree. I think it would be huge mistake for Manifold to be special to only few areas. I've had a privilege to visit quite few GIS departments in many NY state agencies. If you talk to the people that work 8 hours (ok maybe 4 hours, hay it's G job) per day in front of the ArcGis, you will find that most are happy with Arc. What they do from day to day does not require CUBA or even top of the line desktop computer. There might be few guys in the entire NY state that have a need for supercomputing. Looking at manifold development in the last two years, it seams like you guys are after those very few seats that do need to load massive amount of data and be able to work with it at will. I hope that it's not the case. Isn't the goal of every software company to gain as big market share as possible. The only way for Manifold to do so is to have a clone to ArcGis that is better, faster, cheaper. Just NY state alone has thousands of ArcGis seats, where 95% of them use Arc for simple things like viewing data, collecting data, editing data. This is where ESRI shines. It might not run in 64bit but it gets the job done with half the clicks than it takes to do it in Manifold. It's not easy for a new Software company to penetrate the market. Most GIS professionals in NY know only Arc and for them to switch to something else, it would have to be one hell of product. If you take all the labeling & editing capabilities and combine it with fast CUBA driven 64bit system at fraction of the price, eventually most State agencies will force their workers to use something other than ESRI product whether they like it or not. Just imagine that amount of money ESRI get every year just from government agencies. CUBA and 64bit would be a nice bonus but for most of them, it's the simple operations that they spend most of their time on. I agree 100% with James and teconner. Get the basics working first than you can wow them with speed.

And why is Global Mapper so much dam faster at anything than Manifold. What did those guys do with their code to make it run this fast. I can open 2gb vector file in GM in fraction of the time it takes for Manifold to load it. Steal their code and add CUBA to it and take over the GIS world.

And what happens when ESRI pressured by their users have both 64bit and CUBA in their next release. Now you have products just as fast as Manifold, but much easier to use for basic functions. Now your only edge is price. Nick posted perfect example of what price alone means to end users.

Just NY state alone has thousands of ArcGis seats, where 95% of them use Arc for simple things like viewing data, collecting data, editing data. This is where ESRI shines. It might not run in 64bit but it gets the job done with half the clicks than it takes to do it in Manifold. It's not easy for a new Software company to penetrate the market. Most GIS professionals in NY know only Arc and for them to switch to something else, it would have to be one hell of product.

Well, a strategy of selling mass volume into the mainstream doesn't leave any room to invest into bespoke selling to ESRI users. Selling mass volume means you have to keep it affordable, hence the $245 entry price for Manifold. Selling GIS product at $245 leaves no margin for the hyper-expensive sell required to convince an ESRI user to move away from something with which he is perfectly happy or away from something into which he has already invested many thousands per seat. Plus, there is not enough of them to make it worthwhile. We're not in this to sell thousands of seats, we are in it to sell millions and the easiest way to do that is to price the product affordably and to tap into the hundreds of millions of potential users who have never heard of ESRI. Why fight city hall when there are zillions of users who want to business with you?

All that is a benefit for those ESRI users who do decide they want something more advanced or lower cost. I've yet to hear an ESRI user complain about taking advantage of economy of scale powered by mass markets if that same economy of scale lets him leverage the lower cost of Manifold to put in a bunch more seats for a fraction of the cost of his ESRI support fees. And I've yet to hear one of these "New GIS" users complain about benefitting from the experience and wisdom of users who have paid their dues for many years in traditional GIS settings. It's a classic "win - wi