|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | Re: [gislist] GML too Bulky? (was google maps and OGC Testing) |
| Date: |
02/23/2005 02:55:01 PM |
| From: |
creediii .. mindspring.com |
|
|
All depends on the application, what your obectives are, whether the content needs to "move" from server to client or can stay on the server, etc. It is totally possible to implement very simple schema profiles of GML, say for a point feature with metadata for expressing a mobile wireless device location, that are very light weight and run very effectively in low bandwidth environments. At the same time, if you have 100,000 features I am not sure I would want to move these as a GML payload in a low bandwidth environment :-)
That said, a couple of things to consider.
The core issue is XML - not GML in particular. This is why W3C has a new working group developing a compression standard for XML documents. Turns out the overhead for compression and decompression is trivial when compared to the time savings for transmitting large XML documents in a low to medium bandwidth environment.
Another interesting technology evolution is the ever increasing bandwidth for the wireless/broadband world. I just listened to a gentleman from Sprint speak to CDMA2000 and something called EV-DO which gives a mobile device access to 400-600 KBPS badnwidth. This is enough bandwidth to stream a movie to a cell phone. This is to be followed in 2006/2007 by EV-DV which provides 1400 KBPS bandwidth to a wireless device. In this environment, "bulky" takes on a whole new meaning!
Cheers
Carl
-----Original Message-----
From: Bill Thoen <bthoen@gisnet.com>
Sent: Feb 23, 2005 6:28 AM
To: gislist@lists.thinkburst.com
Subject: [gislist] GML too Bulky? (was google maps and OGC Testing)
On Wed, 23 Feb 2005, Jeff Harrison wrote:
> Interoperability Testing has demonstrated the network performance of the
> specifications, so let's get beyond that. Oh, somebody will probably say
> that WFS doesn't work and that GML is too "bulky" to "perform" well--
> Sorry, that's not true either, it's works just fine for me, and it's
> getting even better with compression, etc.
I'm very curious about this. How can geometries stored as plain text
strings possibly be faster than the same objects stored as binary data?
Even with compression, you have the cost of decompressing on top of string
parsing. Or is the point more that GML is "plenty fast enough" and the
simplicity and interoperability of plain text is well worth the small
performance hit?
- Bill Thoen
_______________________________________________
gislist mailing list
gislist@lists.geocomm.com
http://lists.geocomm.com/mailman/listinfo/gislist
_________________________________
This list is brought to you by
The GeoCommunity
http://www.geocomm.com/
Get Access to the latest GIS & Geospatial Industry RFPs and bids
http://www.geobids.com
_______________________________________________
gislist mailing list
gislist@lists.geocomm.com
http://lists.geocomm.com/mailman/listinfo/gislist
_________________________________
This list is brought to you by
The GeoCommunity
http://www.geocomm.com/
Get Access to the latest GIS & Geospatial Industry RFPs and bids
http://www.geobids.com
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
