|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: OGC and Standards, - a response |
| Date: |
01/07/2003 11:20:52 AM |
| From: |
Dimitri Rotow |
|
|
>
> "actions speak louder than words. As far as the fact that
> collaborating to
> create good specs takes a long time, name someone else in the geospatial
> world who is doing it faster than the OGC".
>
I second Anthony's comments and would expand on the above. It does take a
long time to collaborate to create good specs, apparently longer than OGC
has since its current specs are such turkeys. I almost wrote "dogs" there,
but then realized dogs are for the most part agile, responsive creatures who
are usually very well adapted for their role in life... quite unlike OGC
specs.
An example of how unrealistic specsmanship coupled with big-player
foolishness might operate within OGC can be seen in the GML format heaved up
onto dry land by the OGC process and recently adopted (and apparently
idolized, for all the wrong reasons) by the UK's Ordnance Survey. I have no
idea what the Ordnance Survey was thinking when they brought out MasterMap
in GML format, but apparently winning a reputation for common sense and
agility among GIS software creators and GIS data consumers was not part of
the picture (... else they would not have used GML).
GML may set a record for inefficiency. It is a spectacularly bloated format
larded down by all manner of design-by-committee offenses against modern,
efficient software design. It is *so* bloated that typical compression
ratios of over 20 to 1 are achieved with a simple zip. For example, the 105
MB GML file for Birmingham on the OS samples site zips down to 5 or 6
megabytes as a zip file. Once the GML file is imported into Manifold
(recent builds of Manifold read GML), it saves as a Manifold file in only 5
or 6 MB as well. Now, obviously there is more to a format than simple file
size efficiency, but a bloat factor of 20 times inflation is really out of
hand.
The OS appears to agree with this, because they repudiate using GML in its
native format in their guide that recommends questions to ask about software
that purports to work with GML. One of the key recommendations is that the
software be able to work with .gz compressed format files, since GML files
may be too big (!). The exact quotation is....
"The largest OS MasterMap files, when uncompressed, can exceed operating
system maximum file sizes. Some software avoids this by reading the
compressed GML data directly. [Does your software of choice allow this?]"
Well, I guess if one were enough of a cretin to use a format that required
20GB to store what typical GIS formats store in 1GB, I guess it might be a
problem in early versions of Windows or other systems that cannot handle
20GB files. I would respectfully suggest that the solution here is to avoid
using ponderous, bureaucratized formats like GML and not try to band-aid
around a poor choice by suggesting the entire world work only with .gz or
.zip compressed files to avoid the incompatibility of OGC ideas with real
life.
Note also that in the real world, because GML/MasterMap imports are lengthy
affairs (the Ordnance Survey document worries about that and recommends
"unattended operation" be a key desideratum to help deal with lengthy
imports) it's really dumb to try to work only with zipped files when data is
downloaded. Better to use the unzip process as your download verification
step *before* launching into a lengthy import process. But then, such
practical performance issues appear not to be part of the pretzel logic that
was used to conceive GML.
Cheers,
Dimitri
To unsubscribe, write to gislist-unsubscribe@geocomm.com
________________________________________________________________________
GeoCommunity GeoBids - less than $1 per day!
Get Access to the latest GIS & Geospatial Industry RFPs and bids
http://www.geobids.com
Setup a GeoCommunity Account and have access to
the GISDataDepot DRG & DOQQ Catalog
http://www.geocomm.com/login.php
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
