|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: OGC and Standards, - a response |
| Date: |
01/07/2003 11:20:53 AM |
| From: |
Allan Doyle |
|
|
Heh. Dimitri, why would you have made Manifold ingest GML if there had
been no customer demand for it? Would you have preferred to see all
the data in Shape format? How about netCDF or HDF or comma separated
ASCII? Or does Manifold have a nice, compact, publicly documented
binary format that is easy to use across multiple platforms, does not
suffer from endian problems, and has no quirky, vendor-specific
fields?
I subscribed to GISList when someone recently told me about the OGC
thread, but I don't see much here other than a lot of fulmination. At
least ESRI has the grace to quietly do its thing and to participate
in the OGC in a constructive way.
I really have not seen any technical argument against GML by you
other than "it's too big". "Stupid", "banality", "incompetence",
"bloat", and "doltish" make for some unconvincing material. Maybe I
missed something.
Is the fact that OS tells you the data might be big a technical
argument? I don't think so. They clearly decided that it's worth it to
them to use GML in spite of the size issue. That's a
tradeoff. Tradeoffs are made for technical reasons as well as for
other reasons. Generally I'd like to think that they were not a priori
thinking "let's shoot ourselves in the foot!" What's wrong with
compression wrapped around the format vs. compression built into the
format? Do you think compression research has stopped? Think about the
potential benefit of being able to recompress GML in 10 years because
you can remove the GZip compression. What about all those binary
formats that have already squeezed out the possible seeds for the
compression algorithms?
How can you complain about "performance" and how can you claim "60
times slower" for a format? A format is an encoding. It's a thing
that sits there. It does not perform. Software performs. Harware
performs. People perform. Encoded data does not perform. So we're
back to the fact that GML is 20 times too big for your taste.
I don't need to defend the OGC. I've participated in it for years. It
needs no defense. Either you subscribe to it or you don't. Either you
participate or you don't. That is your choice. I believe that OGC has
some good specs and some bad ones. The same goes for probably every
standards organization. My favorite standards are those that are easy
to find, easy to understand and easy to work with. Some standards have
to go through some revisions to get to that point, others may never
get there.
If you would like to contribute to making GML be easier to understand
and work with, then maybe you can recast your criticisms to be
somewhat more substantive and somewhat less specious. I'm sure your
years of experience would be a welcome contribution. Don't however
expect to show up at OGC meetings bellowing and hollering. It's been
tried before. The little guys who are doing a lot of the work and who
are benefitting immensely from their membership won't stand for it.
The bottom line is that when you offer good technical arguments we
can all learn something. I look forward to doing just that since I
have seen your posts in various venues and I am under the impression
that you know more than I do about a lot of things.
Regards,
Allan
On Friday, December 20 2002 at 12:51:02(-0800) Dimitri Rotow wrote:
>
>
>
> >
> > 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 ac
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
