Sounds like your experiences are consistent with my own - the bottom line being "horses for courses". Choose your GIS application and your data storage to suit your requirements.
Just playing devil's advocate for a minute, though: If you already have 75 MapInfo Pro clients, presumably they are getting their data from
somewhere. In my experience it is a very low-risk, low-cost exercise to change those TAB files to "linked" TAB files even if you do nothing else. Workspaces still open OK. Presumably the data is read-only for most (if not all) of these users - otherwise how are they "sharing" their edits at the moment? Then the only thing that changes is the circulation of TAB file updates. Instead of copying new TAB files around the place, you refresh the linked TAB files in situ - a process which can be automated pretty simply.
Benefits of this approach: Single shared source of data for all GIS
clients; Single, central, secure, backed-up, version controlled (if you want to) copy of GIS data in the Oracle database.
Costs of this approach: Change of data management processes (refresh linked TAB files instead of copy new TAB files)
If you're already committed to implementing an Oracle Spatial
environment, and you already have MapInfo Pro clients doing productive work, then I believe you're significantly overstating the problems of linked TAB files if you use it as an argument to drop your MapInfo clients from the new environment. (The equation is seldom this simple, I realise, and there are always other cost factors and agendas associated with a major environment overhaul, but *all else being equal* I believe the linked TAB file mechanism actually provides a benefit under these circumstances, not a disbenefit.)
And finally, to comment on some of your observations:
- MapInfo insists on the primary key being a numeric field
True. And my immediate response to this was similar to your own - I didn't like it. But in practice I have found this to be a very trivial
requirement toaccommodate in Oracle Spatial. If you have another primary key on your GIS data, just replace it with uniqueness constraints and indexes as you see fit and add the new primary key field. No drama. And I think you'll find that GeoMedia will appreciate the change too! (for all Intergraph's protestations to the contrary...)
- If accessing data via Oracle views, MapInfo insists that the primary key is called MI_PRINX
True in most cases, but not if you only want read-only access via a
linked TAB file. Again, my immediate response was "yuck". But again in practice, if you're making a view anyway, it's no big deal to change field names along the way.
- Utilsing the MapInfo Pro to Oracle Spatial load utility - EasyLoader, the Oracle MapInfo username and password had to be indentical.
This is not true. I'm afraid I can't tell you exactly what the access
rights and privileges need to be off the top of my head, but I can say that I am working on a database right now where user "mapinfo" does not have a password "mapinfo".
- To edit the data via views there are issues with what Oracle account is used. Our tests confirmed by others is that we must log in
as the Oracle schema owners account.
Not true (for linked TAB files at least - haven't checked live access).
I have found that if you have a synonym (public or otherwise) available to the non-owner account *with the same name as the view to which it refers* then non-owners can edit views in other schemas.
Once again, I hope this casts some light on the wider Oracle Spatial discussion.
Cheers, David Jerrard
Quoting Lawrence Turner <[EMAIL PROTECTED]>:
David and others,
Extremely good to hear of others experiencing identical issues with this environment.
We are developing a very large database that will contain hundreds of spatial objects / features / layers and some of them have hundreds of thousands of records / elements adding up to tens of gigabytes of data.
We have over 75 read-only MapInfo Pro clients and the prospect of many of them having linked tables (data duplicated to local hard drives) was unsound to say the least. Therefore we must implement "live access" and as you pointed out and I will reiterate - extremely poor performance. We also have nearly 60 GeoMedia read-only clients.
We have decided that this performance issue is unacceptable and as such MapInfo Pro will not be supported to the Oracle Spatial environment.
The marketing @ MapInfo have assured us that all will be well with MapInfo Pro 8 - I won't hold my breath.
I equate the lack of performance with some simple tests. Try any attribute only SQL query from within MapInfo Pro to any relational database even Microsoft Access. Perform the same test outside of MapInfo Pro - the performance difference is staggering.
The issue stems from the fundamental building block of MapInfo TAB file format. The TAB file format is ISAM Flatfile and MapInfo Pro is programmed around this highly optimised, extremely fast structure. When MapInfo Pro deals with any relational database it translates it from relational to flatfile on the fly.
MapInfo Pro opening its native TAB files is far faster than any other GIS apps I have encountered and therefore the change to Oracle Spatial via "live access" was deemed counter productive for the MapInfo Pro clients. In other words, I would rather shoot myself in the foot than try to convince users to migrate from TAB files to Oracle.
Another couple of quirks we encountered with MI Pro versions 7.0 & 7.5 and didn't like was; - MapInfo insists on the primary key being a numeric field - If accessing data via Oracle views, MapInfo insists that the primary key is called MI_PRINX - Utilsing the MapInfo Pro to Oracle Spatial load utility - EasyLoader, the Oracle MapInfo username and password had to be indentical. - To edit the data via views there are issues with what Oracle account is used. Our tests confirmed by others is that we must log in as the Oracle schema owners account.
Nice to read your experiences David.
regards Lawrie
========================= Lawrence Turner [EMAIL PROTECTED] Ph: (+61 7) 340 36898 Fax: (+61 7) 340 35103 GIS Services, iDivision Brisbane City Council Floor 20, 69 Ann St BRISBANE, 4000 Queensland,
Australia =========================
Hi Stephen,David Jerrard <[EMAIL PROTECTED]> 2004/02/04 23:29:35 PM >>>
I have been involved with Oracle Spatial + MapInfo development and deployment in several different projects and contexts, from the
earliest days of 8i through to the current version 9.2. And from all
of that, I think the best short answer to your question is: "It
depends".
It depends on your intended use, the amount of data you're working with, your security requirements - basically every aspect of your work environment. Depending on where you land on the various spectra (big data - small data; dynamic data - static data; open access - restricted access, etc) some of the pros and cons of Oracle Spatial will not apply to your situation.
So, with that disclaimer in place, here's a longer (and highly opinionated) answer with observations I have made over the years. Rather than list them as pros versus cons, I have made some comments
about each issue on its own - whether or not it counts as a pro or a
con is up to you.
MapInfo Live Access versus MapInfo Linked Tables ================================================== MapInfo "live"
access to Oracle Spatial data has always suffered from extremely poor
performance. There is database tuning that you can do to try to
help, but at this stage of the MapInfo / Oracle alliance, I think it's fair to say that "live" access is a misnoma and should only be considered under rare situations of small, highly dynamic data sets.
And if you're using MapInfo at the moment with native TAB files,
then this doesn't include you!
The alternative - linked TAB files - works very well within the MapInfo application environment, because they are virtually "native" MapInfo files, so zooming, panning etc (activities that would make "live" access tables really grunt) work very well. The downside of these tables is that they represent copies of the actual database data. If the Oracle data changes, then the linked table "caches" need to be refreshed. If the data changes a lot, then refreshing linked tables becomes a nuisance.
As an aside, I am currently working in an environment where Oracle Spatial data is being accessed (viewed mostly) using both MapInfo and
GeoMedia clients. The data is largely static, so linked MapInfo TAB
files work well, and MapInfo can open a workspace quick smart. By contrast, GeoMedia has no concept of "linked" tables, so it opens and
reads ALL of the data from the database every time. It is not
unusual for a GeoMedia workspace to take up to 2 minutes to open,
whereas the MapInfo equivalent takes barely a second. (I mention
this not as a GeoMedia vs MapInfo thing, but to highlight the
benefits of linked TAB files in some circumstances.)
Open GIS Standards ====================== Oracle Spatial implements an OGC compliant spatial data model. Therefore the data can be accessed by any OGC compliant GIS application. It takes a bit of careful design - making sure to use "lowest common denominator" specifications - but I can vouch for the fact that MapInfo, GeoMedia and Genamap can all happily access and work with the same central GIS data stored in Oracle Spatial.
(I know your question related specifically to MapInfo, but you never know when the first Open Source application might find a niche amongst the multitude of sins which GIS purports to cover. And when that happens, it's a fair bet that data in an OGC compliant database will work straight out of the box.)
Data Security ================= Oracle database security is second to none - provided you can be bothered to implement and maintain it. If you work in an environment where you have good DBA support, you can get quite sophisticated with which GIS data you make available to which people, etc.
Central Data Storage ======================= Related to the above,
put your data into Oracle Spatial and you do it once. Thereafter it
can be viewed, edited, updated - even copied to a local TAB file (god
forbid!) - safe in the knowledge that it is THE current version of
the data. There are other tools and utilities around for managing
deployment of TAB files across networks, etc, but having a single
database repository is a good thing. (And if your DBA people are doing their jobs, you get it backed up, too!)
Replication - With Oracle 9i came spatial data replication. So it's
possible to have distributed databases all replicating their data
and their updates amongst themselves as required. Very useful for distributed organisations. But again, get the DBAs onside. Oracle replication is not for the faint-hearted!
Conflict Resolution - Concurrent edits on the same item of data are managed. "Live" access record locking prevents conflicts. "Linked"
TAB file conflicts are handled by MapInfo presenting a (somewhat
awkward!) dialog to the user, allerting them to the fact that there
has been an edit conflict, and enabling them to choose which edit
"wins".
Stored Procedures - You can get extremely creative with the use of database triggers to help maintain your GIS data in good order.
Prevent users from violating data constraints by intercepting their
edits with "before update" triggers, for example.
User Paradigm ================== Something to be wary of with the move to a central shared database environment - your current MapInfo users will need some training and/or demonstration of the new system.
I've mentioned a couple of things about refreshing linked TAB files,
and data edit conflicts, etc. For the most part, the MapInfo user experience is unchanged from the native TAB file scenario. But there
are enough quirks and differences to warrant some comprehensive
training and user documentation.
For example, MapInfo does not handle Oracle exceptions well at all. Oracle error messages are often nested and MapInfo currently only reports the "outermost" error condition, rather than "unwinding" the
error stack to provide all the gorey details. In some cases the outermost error message is entirely unhelpful when trying to address
the problem. As a result, a simple exception during commit (e.g.
duplicate key) can often mean that all pending edits need to be
rolled back ("Revert Table") and then reapplied and committed
one-by-one.
Also, I have little faith in MapInfo's ability to recover Oracle exceptions in general. A "permission denied" error from the database
is often sufficient to crash MapInfo shortly thereafter. And
restarting MapInfo with remnant pending edits in temporary files can
be very confusing for users.
Server-side Processing ========================= If you're going to
go the distance and implement Oracle Spatial, I would advise that you
don't just use it as a "bit bucket". There are a number of
inherently useful server-side things which you should consider, depending on your requirements.
Linear Referencing - Road networks, railway networks, utility networks, pipelines... Any environment which describes locations in terms of a distance or chainage along a linear feature. If this is you, then Oracle Spatial has some very useful functionality which can help you (for example) to dynamically segment linear data and present MapInfo with a pre-cooked spatial table for display, interrogation, etc. Since MapInfo has no client-side linear referencing functionality (3rd party products notwithstanding) this can be very empowering functionality.
Spatial Queries - Don't open ALL your data in MapInfo and then do your spatial querying. Instead feed a spatial query to Oracle and have the server-side processing serve up the filtered data for you. Obvious, but extremely powerful.
Server-side Processing - Promised in Oracle Spatial 10g (due soon?) ======================================================== Topology -
Often touted as the functionality which separates the "power tools"
from the "toys" in GIS. I have only sketchy understanding of how it
will work, but it means that this is another area where Oracle Spatial can fill a gap in MapInfo's armoury. If you *need* topology,
you're using something other than MapInfo already. But if you could
*use* topology, check this out.
Network Functionality (e.g. routing, shortest path etc.) - A special case of topology management. If you use traffic flow models, or vehicle routing software etc, this is another case of something worth checking out.
I seem to have rambled on a bit. Hope you find at least part of it useful. (And I'll keep a copy to include in some doco for my current
project!)
Cheers, David Jerrard
Stephen Dew wrote:or opinions for those thinking about moving that way?Do those of you using Oracle Spatial with MapInfo have any comments, adviceMessage number: 10225
Stephen E. Dew GIS Manager IS Department Guilford County 201 S.
Eugene St., Room L-21 Greensboro, NC 27401 (336) 641-7583 [EMAIL PROTECTED]
--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10246
The following message has been received from the Internet. Please use with caution the message and any attachments
This message has passed through an insecure network. All enquiries should be directed to the message author
--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10277
