On Jun 24, 2007, at 5:08 AM, SteveC wrote:
WMS vs. googles tiles is, I think, a great example of what the
original poster was trying to get at. On the one hand you have a
Specification which does everything, for everyone all the time in
any way, and on the other you have something which is approximately
trivial, does one thing which happens to be what 5 9's of the
population want. Tiled WMS is this big band aid. The only real
innovation on top of gtiles was MSFTs quadtree and even that was a
no-brainer.
Let's examine this (alleged) Google Maps / WMS schism a bit more. I'm
not sure that the two compete at any level lower than "well, we both
serve up maps via a web browser."
The WMS spec gives us complete customization of the map (bbox,
projection, map layers, styling, image format).
Google maps uses canned vector and raster layers that offer zero
customization choices. There is no way to provide your own base layer.
WMS allows us to seamlessly merge map data from disparate sources
(provided they implement the spec correctly).
Google maps provides great support for "red dot fever" (overlaying
points), ok support for lines (you can draw arbitrary lines, but not
have them 'snap to' roads segments), and historically weak support
for polygons (although this seems to be improving with the recent
addition of KML support).
WMS offers zero caching solutions -- since each map is a unique work
of art, customized to the Nth degree, caching is not a real
consideration.
Google Maps is a brilliant example of how caching, tessellation,
ajax, et al can bring a desktop-like user experience to the browser.
Let me be perfectly clear: I think both are brilliant at what they
do, and I use both on a daily basis for customers and myself. They
are, however, two different solutions for two different problems.
At the end of the day, arguing that one is ultimately better than the
other is naive. They represent the opposite ends of the web mapping
spectrum. GM optimizes for mass consumption (caching, performance).
To do so, they sacrifice customization. WMS optimizes for
customization. To do so, they must sacrifice caching. When I am
gathering requirements with customers, these are the discussions we
have. If the data is relatively static, let's cache the hell out of
it and gain the speed (either using GM or a GM-like tiling strategy).
If the point of the app is to allow the end user to compose a map
from disparate sources, there is less we can do in terms of caching.
Let's leverage the native customization capabilities of WMS.
I am working with one transit authority right now that wanted to use
all of their own data (vectors, aerials), host it in-house on their
hardware, but still provide a Google Maps-like user experience.
Beyond what GM can provide, for a specific subset of the users they
want to provide the ability to turn map layers on and off and do
distance measuring on the screen. All of their data is in state
plane, and they want to keep it in that projection. I've put together
a PostGIS + GeoServer (WMS) + Tilecache + OpenLayers solution that is
due to go live in the next month or so. Problem solved.
I'm in talks with another transit authority that is a very small
shop. They don't want the hassle of hosting their own data, managing
their own hardware, etc. They want a turn-key solution. Google
Transit seems to be the right fit there. Problem solved.
No golden hammers here. Right tool, right job. SImple as that.
Are WMS/WFS/GML/et al flawless? Far from it. (Although neither is
Google...) Is Google innovating at light-speed compared to the OGC?
Absolutely. But should a standards body be expected to release a new
spec every 3 months? Could the industry keep up, or would the OGC
catch equal amounts of different grief for that?
All are interesting questions, but far different than the "WMS sux --
GM roolz!" hypothesis originally posted. (grin)
Cheers,
Scott Davis
author of Google Maps API (Pragmatic Press)
author of GIS for Web Developers (Pragmatic Press)
Standards, like ideas, are cheap. It's the implementation that's
expensive.
have fun,
SteveC | [EMAIL PROTECTED] | http://www.asklater.com/steve/
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
