|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: OGC and Standards, - a response |
| Date: |
01/07/2003 11:20:53 AM |
| From: |
Dimitri Rotow |
|
|
>
> Let me summarize your entire critique in four words: GML is overly
> verbose. Talk about overly verbose: condensed from 7 paragraphs to 4
Rob,
Condensed at the cost of removing content essential to the proof of the
assertion. "Overly verbose" is a banality that lets you pretend GML is not
stupid. Inflation of a 1 GB data set to 20 GB is specific evidence of
incompetance.
Plus, you summarized away my specific quotations and discussion that show
how even the Ordnance Survey itself has acknoledged the practical
inefficiency of GML. If the credibility of OGC is an issue, it is important
to note when the first adopter of a new spec finds itself talking out of
both sides of its mouth during the very first deployment.
> 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
Subjective up to a point. That point comes far below the level of being 20
times more bloated and 60 times slower than typical GIS formats.
> 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.
You seem to forget what the point of computers is: it's *all* human readable
given a common-sense interface even if *none* of what is actually going on
is human readable. You don't think there's a scribe sitting in your
monitor, right? At the end it's all binary. There's no point whatsoever in
storing things as ASCII or UNICODE patterns in binary if you can store it
more efficiently.
For the record, the major drivers of the growth of the web were a) Ponzi
schemes based on advertising and b) pornography. HTML's human readability
was one of the many very poor design decisions that despite their
inappropriateness for the job were not sufficiently terrible to stand in the
way of lust and money.
If you think about it for a moment, simple binary coding would have gained a
lot of efficiency for web pages in the early days. In a world before 56K
modems when pages were text-oriented, it would have been a big deal to have
web browsing suddenly be four to ten times faster. If HTML were binary
coded, there's no reason even the most trivial of HTML editors could not
have been cobbled up to show visually in a simple, easy user interface a
human readable version of what the web page is.
My theory on why this did not happen is that user interface standards were
low because all of the early work on HTML and the web was done by UNIX
people, who have dramatically lower standards for user interfaces than we
now have in modern (Windows) society. So, they didn't mind ultra-retarded,
but texty, interfaces like TROFF or NROFF for text editing, so why not have
a texty, TROFF-like interface for writing web pages? No problem... fire up
EMACS or VI and keyboard away. So, they hacked up a low-efficiency thing
that became grown into the infrastructure and still accounts for a lot of
wasted bandwidth and seriously retarded limits on how easy things can be
done.
Now, let's get to the truly nonsensical part of your implied assertion: that
human readability of a storage format is always good. If that were true,
your databases and everything else in your computer would be storing things
in XML or similar texty format. That they don't is because humans who know
what they are doing want higher performance and better storage efficiency
than that brings.
>
> 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
Sure it is. Anything that is so titanically stupid that makes it much, much
worse than alternatives for practical applications is a show-stopper. It is
the unsophistication of GML that kills it, not the observation that GML is
poorly conceived.
Plus, we're not talking "very" compact here: we're talking about GML being
20 times worse than average in storage size and 60 times worse in
performance.
> 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
Again, we're not talking about "compactness being critical," we are talking
about ordinary, real life where the OS has to caution its users that storing
files in GML format may *exceed the capacity of their operating systems.*
Clearly a storage format that is too bloated for use on machines that
routinely have hundreds of gigabytes of free disk space goes beyond the
realm of "where compactness is not critical."
> data formats to GML, we find it inflates them by about a factor of 10:
Well, I don't know why yo
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
