Good post Lars. Matts original post about the ESRI geodatabase based on Access was more to do with portablility of the format against TAB files but as usual its opened up the argument about where TAB and by extension MI Pro are going. There are two threads here - one is local vs enterprise working, the other one is product features.
You can't base any sort of enterprise multi-user environment on Access - well you CAN (I've seen it done) but you shouldn't (it drove the admin staff to despair). The ESRI geodatabase is an excellent tool for better management of local data for one or a small number of users, and the performance is far better than using SHP files. It also seamlessly integrates with other RDBMS data, and imposes the discipline of proper data models. But ESRI themselves would suggest using SDE and/or WMS/WFS across the enterprise. TAB - in common with lots of other MI features that have been there from the start - is surprisingly powerful and scalable. On one project we still use TAB files to support read-only access to hundreds of users on a shared LAN for instance - but its no good for multi-user editing. You share TAB files in almost exactly the same way that you share a Word document or an Excel spreadsheet. Its also a strength and a weakness of TAB that you can store any mix of feature types in it - you can get away with no proper data modelling. To get good results when you scale up to Spatialware or Oracle you have to do some proper design work. So - at the data level - both approaches have merit and MI competes because ti is performant and straightforward. Both product sets have different routes to better management of local data, the ESRI one being more 'pure' but normally more work to implement. TAB is fast and simple and a great product strength. Theres always room for improvement - I for one would like to see TAB have some sort of transaction/history built in (might be some back compatibility issues there but Word handles it) - and programmable events associated with edits and style changes that come from the table itself would be a big plus. The concern is - as Lars expresses it well - that the software world is fluid and GIS is becoming more mainstream every day. MI need to keep up - frustratingly I haven't been able to work with the King beta much because of desktop build limitations in the office, so I don't know much about whats in it. Cheers Paul Crisp BT Syntegra Innovation Place Delta Bank Road Newcastle NE11 9DJ Tel 0191 461 4522 Fax 0191 460 1987 -----Original Message----- From: Lars V. Nielsen (GisPro) [mailto:[EMAIL PROTECTED] Sent: 20 March 2004 20:43 To: 'MapInfo-L' Cc: SCISOFT; 'Matt Carlson Subject: Re: MI-L Constructive thoughts: MI & ArcGIS As I've frequently told new employees in the companies I've worked for, there's usually a good - and historic - reason for the way things are made. And things should be judged in that respect, not i relation to "the last few days". And in the case of MapInfo, it _was_ quite revolutionary at the time to think of GIS data as normal relational tables with geometry attached as an extra attribute. Everyone else was still considering GIS as CAD drawings of maps MAYBE with a loosely connected attribute table somewhere.And some of these systems still thrive even in today's "more enlightened" world. So MapInfo's file based approach is by no mean "na�ve" or "simple-minded" as a concept, even today. It's actually more state-of-art. The point where MapInfo has failed, imho, was failing to keep updating and renewing this concept, and thus falling under the "elastic band phenomenon" : the last suddenly leaps to the front. MapInfo has been too keen on persuing the lastest (marketing) trends, neglecting support for the vast and important Pro user base, and for the last few years MapInfo has even been completely deaf to valid user suggestions. I still regard MapInfo as the better GIS, but not for long. If .NET doesn't deliver - with a vengance - a superior and substantially improved product, I'm beginning to look elsewhere too. I sincerely hope it won't get that far. Best regards/Med venlig hilsen Lars V. Nielsen GisPro, Denmark http://www.gispro.dk/ http://www.gispro.biz/ ----- Original Message ----- From: "SCISOFT" <[EMAIL PROTECTED]> To: "'Matt Carlson'" <[EMAIL PROTECTED]>; "'MapInfo-L'" <[EMAIL PROTECTED]> Sent: Saturday, March 20, 2004 4:02 AM Subject: RE: MI-L Constructive thoughts: MI & ArcGIS Matt / Paul / Lars Perhaps in the .NET version of MapInfo there may be some changes - let us hope so. I think the current system for handling (lots of attribute) data sucks. The real advantage I see in the Geodatabase concept is that (for those who need it - and many users aren't knowledgeable enough to know if they do or they don't) it imposes a well-designed data structure that is applicable to the particular geographic situation. There are lots of ready-made ones available, so even the database-agnostic amongst us can choose an off-the-shelf structure that makes good sense. For 'Enterprise' databases, we assume that whoever implemented the data stored there (I don't mean the manufacturer of the product - Oracle Corp etc, but the data-user) knew something about database design. At a 'lower' level - at least with MI 6.5 (I don't use anything more recent) - the handling of data is simple-minded if not na�ve. I refer to the fact that a nicely-designed set of related tables in (for example) a Microsoft Access database is of little use in MI because it can't cope with anything but a simple table. I know this doesn't help anyone and it's just an opinion. But I can still wish that in 2 or 3 versions time, MapInfo will start to do things right. Unfortunately, I've followed the wrong path for too long - perhaps I should throw away MI and reinvest in the ESRI product as I should have a decade ago! Ian Thomas -----Original Message----- From: Matt Carlson [mailto:[EMAIL PROTECTED] Sent: Friday, 19 March 2004 11:15 PM To: MapInfo-L ([EMAIL PROTECTED]) Subject: MI-L Constructive thoughts: MI & ArcGIS Hello All, I use MI 7.5 and ArcView 8.3 - I have a question about MapInfo, based upon experience with ArcView 8.x: For those who know what I mean by the Personal Geodatabase concept in ArcGIS, is there any feasible way to store GIS data in a similarly 'neat' way in MapInfo? By this I mean to remove the need for 4 or 5 physical files per table (TAB, MAP, IND etc), but to store several (or many) tables in a single file. The reason I ask is the sheer number of files which can accumulate in a directory, and also the ability to transfer data to others in 'neat' packages. Any thoughts? Cheers, Matt __________________________________________________________ Matt Carlson Senior Transport Planner Arup 13 Fitzroy Street, London, W1T 4BQ, UK Tel: +44 (0)20 7755 4114 Fax: +44 (0)20 7755 2451 mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> http://www.arup.com <http://www.arup.com> http://www.arup.com/transportplanning/ <http://www.arup.com/transportplanning/> __________________________________________________________ ___________________________________________________________________ Electronic mail messages entering and leaving Arup business systems are scanned for acceptability of content and viruses. --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10979 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10981 ******************************************************************** This email may contain information which is privileged or confidential. If you are not the intended recipient of this email, please notify the sender immediately and delete it without reading, copying, storing, forwarding or disclosing its contents to any other person Thank you Check us out at http://www.btsyntegra.com ********************************************************************
