Dear Paul and Lars Anyone who knows me will not be surprised to hear that I agree with both your positive thoughts on the MapInfo TAB format!
Internally the organisation of Oracle, SQL Server and Access databases are surely effectively seperate files that are importantly held in different places on the hard drive(s). Even the MAP file is effectively several files in one. The MAP file surely has to be elegant to someone who likes efficiency. MapInfo has the three obvious ways to style a drawn object. 1. Style Override 2. Thematic mapping 3. Graphic style within the MAP file. It is the third method that received debate and comparison with ArcView. MapInfos implementation is effectively a built in thematic map in that only one byte ( a couple for some objects) of information is held against each object and this is compared to an internal(to the MAP file) "lookup" for how to style that object. If used correctly this is an extremely elegant and efficient solution for a certain type of attribute. I personally would say a good example for use of graphical styling would be a layer that contains several objects types that are physically different and will always retain that difference. For example a layer might contain footpaths and roads. We might want the road as a solid line and the footpath as a dotted line. This physical difference will always apply. However if we are wanting to show maintenance against these objects which is forever changing it would then I suggest be better to use thematic mapping. Thematic mapping has to be slower than graphical styling. When you have found an object to draw from your spatial index you next have to look up its current data values. Whether we use DAT,MAP or a personal GeoDatabase,Oracle, this data is physically separated from the spatial data on the hard disk ie the heads have to move!. With MapInfos graphical style the single byte is already in memory as it will have been read in contiguously with the object. The style lookup table is also in memory and so map rendering is much faster. I think the reason the MAP format is seen in a less favourable light these days is that we are all prepared to use the fantastic hardware performance improvements to cover up the less efficient storage methods. If the less efficient methods are then more usable ( eg one file to copy) eventually the more elegant solution is replaced. Betamax versus VHS - 8 track versus cassette - that shows my age! What does surprise me is how fast users are prepared to move to storage systems that will cost them money when TAB is effectively a free and very efficient storage system and does the job well. I'm still going to argue for TAB where multi user editing is not a GENUINE need/requirement! Regards Bob Quoting [EMAIL PROTECTED]: > 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 > > ******************************************************************** > > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10993
