|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: OGC and Standards, - a response |
| Date: |
01/07/2003 11:20:54 AM |
| From: |
Dimitri Rotow |
|
|
>
> Unless you are going to get all of the data you need, at once,
> and in one place
> for any problem you might conceive of, it is hard to imagine not
> doing "GIS over
It's easy to imagine. There's a difference between using Internet to
download data sets for local work and using Internet to interact with an
Application Service Provider (ASP) to do GIS over the network. The
difference between the two is that when you fetch data from Internet you
download it once. If you attempt to do GIS over the network you end up
transferring billions of bytes back and forth all the time as you work (that
is, if you are doing significant interactive work using a high performance
user interface).
Browse Internet, find the data you need, download it and off you go with
high speed thereafter.
To help everyone in the thought experiment department when it comes to
imaging the pluses and minuses of "doing GIS" over the web, consider that as
expectations in GIS for user interfaces start coming up to modern standards
to an increasing degree GIS users will demand user interfaces as good as
those in packages like PhotoShop and the Microsoft Office applications.
So, ask yourself: if doing GIS over the web is really a good idea, why is it
such a terrible idea to to PhotoShop or Microsoft Word through the web?
That doesn't mean that people don't use images created in PhotoShop on the
web or that they don't make documents created with Word available through
the web, but they don't actually *do* PhotoShop or Word through the web.
They do them locally and then publish results through the web.
No one in their right minds would form a consortium aimed at deforming
PhotoShop so that it became a client-server over-the-web thingy that worked
using OGC-style carrier pigeon technologies, but nonetheless this is the
strange situation we have in OGC for GIS.
> a network" - at the same time there is nothing whatever to say
> how much data you
> move about in any transaction - it might be a small amount it
> might be large.
Absolutely correct. If your "doing GIS" consists of submitting a zip code
to a web form and getting an image showing a map of the three Honda dealers
nearest you then, yes, not much data is involved.
On the other hand, if your "doing GIS" consists of a sequence of steps using
a layer of 22,000 complex, topologically branched (holes and islands) areas
to "cookie cut" several other layers that are images, surfaces and vector
layers mixing points, lines and areas then considerably more data is
involved, especially if your GIS does sensible accessory things like
displaying customized status information as the mouse floats over different
objects, operates with multiple windows open at different zooms so that one
can use different windows as guide windows (linked views), and so on.
> This depends on the application. OGC interfaces do not constrain
> you. So you
Absolutely wrong. For example, if you made the mistake of using an OGC
interface that requires you to store your spatial geometry within a
centralized DBMS that is queried at an atomic object level you've killed
performance for the second application noted above. The more simultaneous
users you have, the worse it will be.
If, for some insane reason, you adopted "live" GML as your interface between
the software with which you interact and the data as it is stored, you also
will kill performance and the second application as note above will not be
feasible in an interactive setting. By "live" GML I mean if you have
actually fallen for the GML spin and really use GML as opposed to suffering
through a one-time import from GML and then doing everything else from cache
using a sensible binary protocol of your own devising, that is, in effect
abandoning GML.
> can have your cake and eat it too. The existence of a public,
> extensible format
> like GML has enabled the creation of a public query and update
> language - so you
> can update geographic database over the Internet. You should rejoice!
>
Why would I rejoice at something that is too slow to be used for anything
but trivial amounts of data? GML is *so* inefficient that it is actually
more efficient to retransmit the entire original data set using modern
methods than it is to transmit GML updates, at least in the case of the GML
original data and updates (the "Birmingham" examples) published by the
Ordnance Survey.
Regards,
Dimitri
To unsubscribe, write to gislist-unsubscribe@geocomm.com
________________________________________________________________________
GeoCommunity GeoBids - less than $1 per day!
Get Access to the latest GIS & Geospatial Industry RFPs and bids
http://www.geobids.com
Setup a GeoCommunity Account and have access to
the GISDataDepot DRG & DOQQ Catalog
http://www.geoc
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
