|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | [gislist] RE: GISList: Cartography and Data Viewer |
| Date: |
08/27/2003 09:20:01 AM |
| From: |
Pat Waggaman |
|
|
>I think this discussion confirms the fact that folks are discovering that
>multiple methods of data and content distribution and access are
>reasonable and that one size probably doesn't fit all. Right now, some
>folks are disseminating files via FTP, some are distributing content via
>live web mapping services, and some distribute paper maps. I get my news
>from newspapers, the radio, email, telephone, television and the web. I
>think one content distribution and access method is not necessarily better
>or worse than another, just different.
Jeff, this appears a bit too politically correct, it appears to me that it
is possible to make a definite value judgement as to whether technology is
better or worse for particular applications. I argue that different types
of content distribution are technically more or less apt for different
uses. F'rinstance, I don't use SMS while I drive, or surf the web on
trains. Emergency services GIS data must be provided from hardened and
multiple sources. The Internet itself is significantly redundant, but can
be taken down.
Various manufacturers of remote sensing systems are beginning to bite at
the "XML wave of the future". My company delivers satellite technology to
bring remote machine-to-machine communication from "off backbone" assets
onto the customer's LAN. Clients are located in places the Andes above the
Atacama desert (mines), Tierra del Fuego (logistics for salmon foodstock),
the central Pacific (fishing): unfortunately all of our traffic is paid
for by the byte or kilobyte. All of those bandwidth-eating tags that some
German manufacturer has paid (or has been subsidized by the EC to include)
form the majority of the bytes in these dataflows. So, what Marimsys does
is establish a correspondence table between a given XML tag and a byte
value: we strip the <XML> at source, substituting a byte corresponding
byte, transmit over the sat link and then at the on-LAN server strip the
byte-substitutes for XML tags, and replace the original XML tags.
Laborious. Why? Because of poor technological decisions: the Internet
isn't everywhere, and it will take a while to get there. There are
bandwidth restrictions in the world - especially in areas of primary
resource extraction which tend to be isolated.
Norwegian salmon farming technology (salmon growth, disease, feeding, QC,
environmental monitoring) is fascinating. Their technology is designed for
Norway, where there are a lot of pine trees, and under each pine tree is a
cellular tower. There are however virtually no cellular towers for the
southern 1000 miles of Chile, where all the salmon farming is - and this is
the area which has taken from the Norwegians the #1 salmon exporter
title. The reliance on cellular data bandwidth for Norwegian acquaculture
technology is a key flaw: it simply doesn't work down here - and to boot
the Chileans produce a less expensive product. Marimsys will transmit the
data in a few dozen bytes, those reliant on Norwegian technology are
shipping around diskettes wrapped in plastic in steel vessels, with random
electrical currents, interesting magnetic fields, lots of salt and, of
course, humidity - probably 1 diskette in 3 is readable.
This is - besides a bit of current sociological examination of technology -
a good example of "the medium can destroy the message."
To get back to the roots of this go-round, I for one, do not want emergency
services reliant on pulling data from Internet connected servers. Fine, if
the Internet is available - get the latest data updates on streets under
construction - , but the basic data must be kept securely, where a
generatator powered server can deliver it through local RF / copper / fiber
links. To the extent that we build increasingly interconnected data
architectures the probabilities of failure increase logarithmically with
the number of data sources, as does the vulnerability.
Cheers,
Pat
>Regards,
>Jeff
>
>Jeff Harrison
>Executive Director, Program Development
>Open GIS Consortium
>tel: + 1 703 628 8655
>
>
>
>Dimitri Rotow wrote:
>
> >
> > > I am sorry that the competitive delivery of GIS and its base
> > > information via
> > > the net and software other than buy yours is upsetting to you personally.
> > > And if the OGC and other OGC-like efforts are threatening to your
> > > company's
> > > future, then that is the way it is. Times change Old Boy!
> > >
> >
> > My company? Let's see... I recommended ArcExplorer, an ESRI product, in
> > response to the original post. I don't work for ESRI, now, do I? (Let me
> > check my badge... nope... not ESRI).
> >
> > As far as times changing, OGC-li
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
