[Manifold-l] Manifold reference clients

[Dimitri Rotow]

> GIS is not MRO's Maximo. By that I mean that it will not have 
> key corporate information locked up inside proprietary data 
> structures. Manifold GIS should be a client to corporate data 
> stores and information systems. Once this perspective is 
> taken commodity software becomes risk-free. If Manifold.Net 

Good point.  At manifold.net we don't like the idea of proprietary "silos"
which capture GIS data.  We routinely criticize ESRI, for example, for
trapping corporate data within a proprietary ArcSDE silo, for example.
That's probably our biggest selling point within the Oracle community.  We
need to live up to that ideal ourselves throughout all we do, and we intend
to.

That's talk, which is sincere, but as anyone with expertise in truly rich
GIS data knows it is not so easy to achieve that golden objective no matter
how sincere you are.  It's not easy for us, either, but at least we've
announced it as our objective and we are making investment to bring it into
reality. Longer term we intend to provide truly generic storage for all
Manifold projects and short term we are already putting our money where our
mouths are with the recent expansion into geometry storage in DBMS.

That's one reason we work hard for Oracle Spatial.  What we like about
Oracle is that it represents a realistic approach to data storage that is
neutral between different GIS packages.  Our ideal (not there yet but we are
working on it) is that if you use Manifold to store data into Oracle you
won't in any way be tied into Manifold to subsequently work with that data.
You'll be able to work on it with Oracle and the Spatial suite of
interfaces, any other GIS that works with Oracle in a neutral way and so on.
That's the idea, which we are pretty darned close to implementing in full.

There are a lot of details to that that require big investment on our part.
For example, we are building a parallel formatting system that uses Oracle
Spatial formatting so that when you edit drawings in Manifold that exist
within Oracle even the formatting is "Oracle native."  We are building
parallel support for Oracle projections (EPSG style) so that not even
translation on the fly is necessary but that at all times the projections
are identically "Oracle native" in all ways at all times with no conversion
on the fly ever necessary.  Right now ESRI uses dozens of proprietary,
undocmented metadata tables.  We use only one, which is openly documented,
and soon we won't even have that one.  It will all be native Oracle, all the
time, with Manifold totally transparent.

People with big data, corporate data should care about such neutrality not
from the relatively limited perspective of worrying about the future of any
particular vendor, although that's obviously a useful side effect of any
such strategy.  What's much more important is the dynamic access to that
data from many different programs and business processes.  That's the key
value delivered today, something that is used every day.  That's much more
important than some diffuse worry about a vendor that won't play out for
years, if every.

Consider that vendors can drop dead tomorrow and their programs will
continue to function for years, so as long as that vendor's existing
programs can read/write/interconnect to continuing standards your data can
always get migrated.  No one is saying that's not a hassle, but what really
happens is that vendors don't so much drop dead overnight as they fade away
under pressure from competition.  For that matter, the truly worthwhile
vendor will obsolete their own product line every few years anyway and thus
you get some migration hassles anyway.  The experienced IT manager has seen
that many times and plans for it. 

Consider the thread on this list about MapInfo falling behind in the pace of
their desktop GIS development.  I often hear complaints from MapInfo users
that the company seems no longer to have an emphasis on winning desktop GIS
as it once did.  Such people continue to have perfectly functional MapInfo
installations and need not fear any overnight catastrophes even if MapInfo
decides to bail out of desktop GIS.  But they will constantly be reckoning
longer term trends to decide if new projects and software upgrades should be
better invested into MapInfo or into some alternative. 

If you want another example, consider AutoDesk's obvious giving up on GIS
(anytime a vendor puts major parts of their product line into open source
for the user community to maintain it is not a good sign...).  No one is
saying that AutoDesk is in any way at risk of going out of business, but
they sure might give up on GIS as their effort is now understood.  Heck,
there have even been mutterings in the community about ESRI de-emphasizing
desktop GIS in favor of more server products.

Given that people can continue to use a particular generation of product for
years [look at all those people still using ArcView 3.x or MapInfo Pro
5.0... or, for that matter Manifold 4.50 :-) ], the length of time that
people often use legacy products can extend well beyond the time over which
key changes in technology will occur.  The move to 64-bits is a good
example.  Whatever your corporate GIS plans may be, if they don't include a
move to 64-bits you are not playing in the big leagues.  To get to 64-bits
you are going to go to Manifold so right there is an example where new
technology will prompt a vendor change without any need to characterize such
change as a response to worries about, say, MapInfo's or ESRI's demise. It's
just the usual shifting of positions as companies move relatively ahead or
behind within rapidly evolving technology.

My point is that in a rapidly changing technological arena the lifetimes of
product and vendor selections are measured in a few years at most.  Whether
you go through the hassle of switching vendors or go through the hassle of
switching technology streams within the same vendor (happy trails for all
those shapefile and Avenue users encountering "geodatabases" and VBA within
ESRI's new product line), you are going to go through an evolution along
with the technology.  Expect that and embrace it so you can use industry
progress for your own benefit.

Cheers,

Dimitri