|
|
| 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 |
|
|
> 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
Allan,
The one and only reason we did it is because we have a lot of customers in
the UK and they are all hostages of the Ordnance Survey (OS). The OS is the
state cartographic monopoly in the UK, so if you cannot read their formats
you cannot use their data. The OS decided to use GML for MultiMap so we
included a GML reader in Manifold. It handles both independent and
topological polygons automatically, automatically reads any designated
update files, etc., etc. We think GML is stupid, but we will spare no
effort to support our customers if the OS puts them in a jam.
> 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
^^^
Who cares? When 94% of the world uses Wintel and probably 98% of the world
uses Intel it is up to the remaining 2% to deal with endian problems. The
common-sense approach is not to mess up life for 98% of computer users
because of some phantom "endian" problem people who don't have the sense to
use Intel architectures cause for themselves.
> fields?
I'm not sure what point you are trying to make. Are you suggesting that a
proposed, inefficient use of comma separated ASCII somehow justifies using
an idiotic format like GML?
The world has plenty of formats already in existance that are far more
efficient than GML. Some are better than others, but there's no reason for
Manifold to introduce yet another format for people do deal with. If you
want an "open" standard, use SDTS. It's well documented and in the public
domain.
>
> 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.
>
Hmmm, well, I see ESRI's participation as an exercise in hypocrisy, using
OGC as air cover to perpetuate obsolete ideas about GIS architectures so
that their products don't risk looking bad next to modern ideas. There's
nothing constructive about that.
> 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.
>
Yes. You apparently missed my citation that GML requires files that are 20
times bigger than they need to be and that as an operational format it is
about 60 times slower than modern formats.
You can check my numbers for yourself by going to the Ordnance Survey's (OS)
website of sample GML files. You'll find they are in .gz zipped form (the
OS is apparently unaware that they should be .zip files to be compatible
with modern computing standards). Download the files, which range from a
few hundred KB to a bunch of megabytes and you'll see that a 105 MB GML file
zips down to about 5.6 MB (in the case of the Birmingham example), ergo "20
to 1".
Zip compression is a useful measure of how efficient a format is. If the
relatively simple zip algorithm can squeeze fat out of a file that's a clear
indication the format is to a greater or lesser degree wasteful of space.
Everyone expects a little fat, but a factor of 20 compression is radically
wasteful.
By the way, that same 105MB GML file, after import into Manifold and saved
in Manifold .map format requires only 5.9 MB. I'm sure there are plenty of
other formats (such as MapInfo, for example) that also would not be anywhere
near as wasteful as the GML files.
By the way, if you compare operational speed with things like loads and
saves you can see that GML is also radically slower than other formats.
That's where I get my factor of 60 for performance loss with GML. I'll
leave investigation of that number as an exercise for the reader, assuming
you can get your hands on a GIS that reads GML as well as it does a few
dozen other formats for comparison purposes.
> 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
What's amusing is that having picked GML they abrogate it by saying that it
would be great if applications did not deal with GML in native form, but
rather the application should deal with files in .gz format. So, what do
they really propose as a standard? .gz format or GML? What happened to the
"
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
