|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: OGC and Standards, - a response |
| Date: |
01/07/2003 11:20:52 AM |
| From: |
Rob Hranac |
|
|
Dimitri,
Let me summarize your entire critique in four words: GML is overly
verbose. Talk about overly verbose: condensed from 7 paragraphs to 4
words! The key point here is that the interpretation of 'overly' is
very subjective. Of course, one of the major drivers of the growth of
the web was the fact that HTML was human readable, which is why the IT
industry is adopting XML, sacrificing conciseness for clarity and
flexibility.
As someone who has personally written a GML parser and writer, I have my
own critiques of GML2.1, but this 'GML is verbose' criticism is not very
sophisticated. If you have an application that requires very compact
data formats, then you should not use GML. If you have an application
that requires wide readability, where compactness is not critical (like
OS MasterMap), then you should use GML. When we convert our internal
data formats to GML, we find it inflates them by about a factor of 10:
this has been a tradeoff that we have gladly lived with for
interoperability. If you can't live with it for your application, then
don't, but don't confuse that with GML being a bad specification in
general.
Also, your critique also has absolutely nothing to do with the OGC
process itself, just a specific OGC technology. Does your critique
apply equally to the WMS spec, which uses compact, non-XML JPG (and
other image formats) for transferring data?
Rob Hranac
slashdot for digital earth?
try: http://scoop.geoenabler.org
> -----Original Message-----
> From: Dimitri Rotow [mailto:dar@manifold.net]
> Sent: Thursday, December 19, 2002 3:30 PM
> To: gislist@geocomm.com
> Subject: RE: GISList: OGC and Standards, - a response
>
>
>
> >
> > "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
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
