Hi Rod I took the liberty to rename the subject of this thread as it has drifted a little. You asked where does GML fit in with this thread?
The thread really started with PROS and CONS of Oracle Spatial! I got involved when Paul (Crisp) pointed out that for lots of uses the TAB/MAP format would be better than using Oracle to which I whole heartedly agreed! I brought ESRI SHP into it by suggesting that TAB/MAP was perhaps the only common desktop GIS format that could do as Paul suggested for drawing large coverages of MasterMap data ( which coincidentally is delivered to customers in compressed GML ( ie GZ)). The thread shifted a little then to direct comparison of MAP versus SHP and that perhaps SHP was also suitable for Data Interchange. So I am summising that your question is "Is GML a data interchange format or a storage format from which to view?". Warren has explained how SHP could be used for both and I think the same could be said for GML. My thoughts on GML are that it is primarily an excellent data interchange format. The XSD style sheets allow new definitions to be introduced so that the format is extensible. However even without style sheets the tokens make it pretty easy to work out what is what. I would argue it is best suited to data interchange as it too verbose to be an efficient storage method and that there is no obvious way to spatially index it. That said Microsoft are using XML ( and thus GML could be used in the same way ) extensively with .NET and the new Longhorne OS and Yukon version of SQL Server. Users do not need to understand the code - SQL server will just store it! If they introduce full spatial support in future versions this would be attractive to many users no doubt! Some GIS vendors offer direct read of GML. A subset of these build a spatial index "on the fly" the first time it sees a GML/GZ file - so her they at least use GML for the storage of the data. These methods trade ease of use against computer performance and personally I like to see very efficient use of the CPU so I prefer the idea of one off translation from a data exchange format to a more optimised storage such as the TAB/MAP format where the layers are for read only use - as is the case with MasterMap - and this was also part of Pauls original point. GML can be used in a third "Middle" solution though. A server can be used to store the GIS data in a highly optimised format for fast retrieval of an area of interest. For example TAB/MAP could be on the server and its spatial index be used to quickly retrieve the objects that would intersect the users screen. Now this very small subset of the GIS data could be streamed over the network to the client. GML could be used as the format for the data stream. In this scenario the client needs no spatial index as it needs to draw everything delivered to it and this way forward makes perfect sense - almost the best of both worlds. GML as an extension of XML is designed for just this type of use - to be read by browsers in Intranet/Internet deployment. Hope this is relevant to answering your question! Regards Bob Quoting Rod Ellis <[EMAIL PROTECTED]>: > Re Ian Ericksons remarks > > Can anyone tell me where GML (extension/derivation of XML?) fits in with > reference to this debate? > As you may have guessed I have been out of circulation for some time. > > TIA > > Rod > GIS Coordinator > Cyngor Sir Ceredigion County Council > > -----Original Message----- > From: Ian Erickson [mailto:[EMAIL PROTECTED] > Sent: 06 February 2004 14:33 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: MI-L UK OS MasterMap - Can't work with ESRI .shp files? > > > I've been watching this thread over the past day and I guess my question is > this: Do we, as GIS professionals, have any options to the ESRI > Shape/MapInfo TAB format debate? Is there a published format for storing > spatial data that has a reasonably efficient spatial index? Do we, as > consumers of the technology, (and I'm not just talking about MapInfo here) > push the demand for a format that meets our needs and is also open? Is > there now a need to implement some of the features we as users have wanted > to see for some time (ie. compression, encryption)? > > I am constantly impressed at the expertise of the individuals on this list. > To propose and implement a spatial format that would be open and extensible > could be huge for our industry! Is there anyone else out there that would > like to see such a thing as well? > > - Ian Erickson > > ----- Original Message ----- > From: "Warren Vick, Europa Technologies Ltd." <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, February 06, 2004 4:11 AM > Subject: RE: MI-L UK OS MasterMap - Can't work with ESRI .shp files? > > > Hi Bob, > > With SHP vs. MIF/MID, it's not so much a preference but a industry > observation. The formats that organisations use to share data is largely > down to the platform they have chosen and we all know that MapInfo is > strong > in some areas an ESRI in others. The change is use of Shapefiles has > changed > my view of GIS formats as I believe it blurs the distinction between > separate "use" and "export" formats. > > Of the technical merits, MIF/MID was obviously designed to be simple to > read > but cannot be reasonably used for viewing. I think perhaps the number of > people reading MIF/MID in their own code might be outweighed by the number > who would find it useful to view an export format directly. Reading the > open-spec parts of SHP (and flipping integer endian) is not difficult, and > is certainly faster than parsing text. > > As for local UK authorities, I've no idea simply because I've never worked > in this area. I certainly know people I can ask and will follow-up. It's > perhaps more important to acknowledge that UK local government is only a > small piece of the global GIS pie and there are plenty of other > applications > managing large data sets. On the desktop, TAB may well have some advantages > over SHP, but ESRI is the second largest private software company in the > world - I suggest they would not be in that position if they did not have > the technology to handle large data sets! > > Regards, > Warren Vick > Europa Technologies Ltd. > http://www.europa-tech.com > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 06 February 2004 10:29 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: MI-L UK OS MasterMap - Can't work with ESRI .shp files? > > > Hi Warren > > I'm surprised you would suggest using SHP and SHX for data interchange by > preference. > > MapInfos MID/MIF is of cource only designed for data interchange and not > for > > viewing ( so no need for a spatial index). Just like XML, GML and Auodesks > DXF > it is an ASCII format and so can be easily viewed on any platform and can > virtually be understood with no documentation. > > However SHP/SHX is binary. Further Unix and Windows platforms store their 4 > byte integers in a different order making SHP less suitable for data > interchange. I cannot see why you would want a spatial index on a format > designed for data interchange. > > I am really interested in the new ESRI formats that you mentioned. Are you > aware of any reasonably sized local authority that is using these new > desktop > formats to view MasterMap? > > Personally I am convinced that MapInfos 18 year old format is a big > advantage > for local authoritys and that this is being underplayed. The public at > large > > here is unhappy that council taxes are rising at rates between 10% and 20%. > Their budgets are important and it hurts to see them spending money > unnecessarily. > > Regards > > Bob > > > > > > > Quoting "Warren Vick, Europa Technologies Ltd." <[EMAIL PROTECTED]>: > > > Hello all, > > > > As Uffe has mentioned, the performance of shapefiles is not bad at > > all, as long as a spatial index is built. Unlike MapInfo TABs, it's > > not automatically built and maintained. Perhaps due to the closed > > format of the spatial index, no translator I'm aware of (including UT > > and it's bigger brother FME) have an option to build it. A shapefile > > of any reasonable size > > *must* have the index built unless you want to be hanging around for > > redraws > > and other spatial DB operations. > > > > As I mentioned to Bob in a direct e-mail, the other thing to consider > > is that shapefiles are quickly becoming more of an interchange format > > as ESRI moves on with other technologies (both server and desktop). > > These implement topology, multi-user editing and very high-end > > compression plus many other features that many MapInfo users would > > love to see without moving up-scale on their DBMS. Already, if not in > > the near future, a more accurate side-by-side comparison will be > > between shapefile and MIF/MID - the latter having no option of a > > spatial index at all. > > > > Regards, > > Warren Vick > > Europa Technologies Ltd. > > http://www.europa-tech.com > > > > -----Original Message----- > > From: Uffe Kousgaard [mailto:[EMAIL PROTECTED] > > Sent: 05 February 2004 21:04 > > To: [EMAIL PROTECTED] > > Subject: Re: MI-L UK OS MasterMap - Can't work with ESRI .shp files? > > > > > > Hi Bob, > > > > There is no doubt that TAB is a better format than SHP, but SHP isn't > > that bad. Based on your description below, it seems like you are not > > using the spatial index files (SBN+SBX) of the SHP format. If you use > > them, arcview can actually redraw at a pretty decent speed without > > reading the whole SHX or SHP file. > > > > SBN+SBX files are closed format as opposed to the SHP+SHX files. > > > > Kind regards > > > > Uffe Kousgaard > > www.routeware.dk > > > > > > From: <[EMAIL PROTECTED]> > > > > > > > With the native SHP,SHX file format the data is NOT rearranged so > > > that > > > objects adjacent on the ground are adjacent in the file. Every single > > > MBR in the SHX file has to be compared with the Screen MBR. If it is > > > on the screen then the full object contained in the SHP file will > > > again be stored randomly ( stored in order added ) and disk access > > > will be relatively slow compared to MapInfo as the heads will be > > > jumping around rather than reading contiguously. So the whole SHX file > > > needs to be read, if there are 4 million objects every MBR has to be > > > read, and then the 200 on the screen will need to be read in full > > > randomly ( rather than contiguously ) from the SHP file. > > > > > > --------------------------------------------------------------------- > > List hosting provided by Directions Magazine | www.directionsmag.com | > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > Message number: 10290 > > > > > > > > > > --------------------------------------------------------------------- > > List hosting provided by Directions Magazine | www.directionsmag.com | > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > Message number: 10294 > > > > > > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 10300 > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 10301 > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 10307 > > > > ******************************************************************************** > RHYBUDD: Mae'r wybodaeth sydd yn y neges E-Bost yma yn gyfrinachol ac mae'n > bosib y bydd yn gyfreithiol freintiedig. Os nad y sawl a fydd yn darllen y > neges yma yw'r sawl y bwriadwyd yr e-bost ar ei gyfer, fe'ch hysbysir drwy > hyn y gwaherddir defnyddio'r neges, ei rhannu, ei dosbarthu neu ei > hatgynhyrchu gennych chi eich hun neu ar eich anogaeth. Os cawsoch y neges > yma trwy amryfusedd, a fyddech cystal � rhoi gwybod i ni ar unwaith a > dychwelyd y neges wreiddiol. Nid yw'r wybodaeth sydd yn y neges yma o > reidrwydd yn cynrychioli polisi a threfn weithredu'r Cyngor. Os cewch gan y > Cyngor hwn ddeunydd heb i chi ofyn amdano neu ddeunydd tramgwyddus rhowch > wybod i ni ar unwaith. > Diolch > ******************************************************************************** > CAUTION: The information in this E-Mail message is confidential and may be > legally privileged. If the reader of this message is not the intended > recipient you are hereby notified that any use, dissemination, distribution > or reproduction of this message by you or at your instigation is prohibited. > If you have received this message in error please notify us immediately and > return the original message to us. The information in this message does not > necessarily represent Council policy or procedure. In the instance of > receiving unsolicited or offensive mail from this Council please notify us > immediately. > Where information of a sensitive or highly confidential nature is to be > communicated, you will be informed that this information will be sent to you > in writing and not by E-Mail, unless secure arrangements are made. > Thank you. > ******************************************************************************** > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 10308 > > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10313
