|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: [gislist] GML too Bulky? (was google maps and OGC Testing) |
| Date: |
02/23/2005 08:55:01 AM |
| From: |
ROSS,GREGORY K |
|
|
I think Anthony's point here is that "plenty fast enough for many jobs"
will not cut it in the long term. Those who invest their money in such
things are going to want "performance statistics." Whether that is a
valid concern is not important. That investors WILL want them is
important.
And to answer Carl's question about asking my appliance makers about
"performance statistics", it happens all the time. What is the gas
mileage of my new car? How many pieces of toast can my toaster cook and
how fast? What is the speed of my computer? What wattage is this light
bulb? All are performance statistics. And the people whose money is at
risk in business want that information printed ON THE BOX.
Gregg Ross=20
-----Original Message-----
From: gislist-bounces@lists.geocomm.com
[mailto:gislist-bounces@lists.geocomm.com] On Behalf Of
JeffreyGHarrison@aol.com
Sent: Wednesday, February 23, 2005 9:37 AM
To: bthoen@gisnet.com: gislist@lists.thinkburst.com
Subject: Re: [gislist] GML too Bulky? (was google maps and OGC Testing)
Bill,
My position is that GML is plenty fast enough for many jobs. One size
doesn't fit all though.
I would also point out that the community needs to look at things like
Binary XML and such because handling text strings is not always optimal.
That said, GML is plenty fast enough for many jobs.
Regards,
Jeff
In a message dated 2/23/2005 8:24:31 AM Eastern Standard Time,
bthoen@gisnet.com writes:
On Wed, 23 Feb 2005, Jeff Harrison wrote:
> Interoperability Testing has demonstrated the network performance of=20
> the specifications, so let's get beyond that. Oh, somebody will=20
> probably say that WFS doesn't work and that GML is too "bulky" to=20
> "perform" well-- Sorry, that's not true either, it's works just fine=20
> 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!
|
