This is a long one,

Just curious how many users out there would like to see MapInfo Corp. not
become MapInfo corps, and decide to make there software modular the way
IDRISI decided to always have it, and the way ERSI has followed suit, and
fully multithreading their software like ER Mapper does.  I have a feeling
that software coming from a Unix environment is much more likely to be
multi-threaded than DOS derived software, this does not explain ArcInfo
however, which was not, I have on good authority from a former Novalis Tech.
software developer, was not multi-CPU optimized.  It's a simple fact that
the work GIS specialists are asked to do and the volume of information we
are asked to process is always way ahead of the curve of computer
horsepower.  The fastest way we can make our lives easier is to enable
instructions to be passed off from the GIS toolkit to as many CPU's as we
can bundle into a case to handle the data.  Of course there's the issue of
bottleneck's in the system.  The new AMD dual CPU motherboards take care of
some of this bottleneck issue by having dedicated BUS's for each CPU and a
third dedicated data bus.  They also use DDR RAM which has a bigger
bandwidth than most PIII systems.

I realise this is getting kind of techy, to the point most people are going
who cares just make it run stable, give me the ability to customize and
build what I need and do the job fast accurate and precise.  Well, the fast,
precise and accurate issues are tied up in the architecture of the software
and MapInfo's basic design is getting old.  Here's an example.  Have you
ever noticed the maximum number of characters there are in a layer name in a
workspace?  If not it's 31, this coincidentally is the same number of
characters allowed in the Mac OS, at least pre- Max OS X.  I can only assume
this to be a hold over from when MapInfo wanted to give people in the
Windows 3.x environment longer filenames like they had in the MapInfo for
Mac world and wrote an identical limit of 31....  Let's face it legacy
limitations like this and ones which are much more "mission critical" are
why software gets abandoned when competitor's come out with a "paradigm
shift" in the way they do business.

Could you imagine using MapInfo tweaked out on a 4 or more CPU workstation
churning through 10's to 100's of millions of points building TIN, NN,
Kriging surfaces, or buffering the world coastline of the world based on the
GEOID, not the projected flat surface as most GIS's use, including MapInfo,
to 50 meters at 1:10,000.  Well we aren't going to do that efficiently with
a single CPU driven workstation running the likes of present incarnations of
MapInfo.  MapInfo needs a paradigm shift in the way it does business.  If
they adopted multi-CPU versions the way NT - W2K works, if you have one CPU
it installs for a single CPU config, if you have more it installs and is
optimized for more; would MapInfo do business the way they've taken the
power unit route with MapXtreme Java...  (Base cost * # CPU's * Mhz clock
speed), if they did, it would kill the "desktop GIS" end of things.  If they
didn't customers who paid hundred of thousands of dollars for top of the
line multi-CPU config.'s in their servers would feel ripped off.  Which way
will MapInfo go... I can't foresee, however keep in mind, video games in the
not too distant future will be multi-CPU optimized as Windows XP is NT 6 and
there is no Limited Edition version as in Win 9x ME.  We all know how game
developers and the rest of the software industry utilises every bit of extra
horsepower available when new technology comes along.  Hey, even Adobe
PhotoShop 5.5+ is at least partially multi-threaded. Ever notice that newer
software running on newer computers never seems to equal the increase in
hardware speed, well the software engineers fill up the performance with
useless speed consuming GUI animations and inefficient code.  Well, why not
create a new paradigm at MapInfo, efficient multi-threaded UNIX class
performance on the Desktop...?  Anyone interested or should we users all
take a powder.

Sorry for the venting,

Stan Johnston B.Sc.
Geologist




_______________________________________________________________________
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, send e-mail to [EMAIL PROTECTED] and
put "unsubscribe MapInfo-L" in the message body.

Reply via email to