Cloudmade/OSM tile server
http://b.tile.cloudmade.com/BC9A493B41014CAABB98F0471D759707/1/256/15/17599/10746.png
Web Map Server (from ESRI example)
Don't get me wrong, W*S style services will have a long tail, because we've spent a decade expounding it's virtues to the Federal government. However, it's time we recognize the WMS is OBE.
UPDATE:
http://hostname/deploy_name/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=Oceans,Countries,Cities&STYLES=&SRS=EPSG:4326&BBOX=-124,21,-66,49&WIDTH=600&HEIGHT=400&FORMAT=image/png
Don't get me wrong, W*S style services will have a long tail, because we've spent a decade expounding it's virtues to the Federal government. However, it's time we recognize the WMS is OBE.
UPDATE:
"we'll lie in the W*S beds we've made" - Sean Gillies
I think you are wrong that WMS is dead.
ReplyDeleteAside from the fact you used my name in vein -- I'll let that piece slide.
Both Tile Servers and WMS have there place and for different reasons.
Tile Servers are great for standard stuff like a general overlay when you don't care about being able to feed in different projections, or don't care about other datasets. This is because they are easy to scale and are fast and face it are static (well as far as the viewer is concerned anyway).
They suck when you are talking about very custom layers that few people use or people need in different projections are are changing constantly (by constantly I mean by seconds and you are feeding a lot of it you can't just push with JSON/XML/take your pick ajax overlay).
This is where you need WMS. Both taste great and work great together. Just don't use the wrong tool for the job.
I'm afraid WMS is dead, it's just lurching around like a zombie waiting for pickaxe to the brain. At least, WMS did have some life unlike the majority of OGC specs which were still births.
ReplyDeleteYour line of argument is correct if we assume the point of WMS is Web based GIS. However, that isn't how web mapping is used in practice. Serving light weight vector data formats over static maps is the dominant pattern for web mapping. So if you want a custom map, why not use Tile Mill to generate a custom layer? Sure only a couple of projections are available, but in practice do the majority of users care? If your require custom projections why not use a desktop solution which has better cartographic support?
As for dynamic maps, tile servers are evolving to use different algorithms to account for rapidly changing data. Frankly, having seen the amount of effort expended on the FOSS4G WMS Shootout, I think that a code sprint improving tile servers would be a better expenditure of time.
Thanks for letting the acronym slide, overuse of acronyms is a nasty habit I picked up in DC and OGC meetings.
In tiles you have what are essentially positional arguments (http://twitter.com/mnot/status/34854552700194816), which suck for programmers, but you get cachability, scalability, all the goodness of URIs. In WMS you have keyword arguments - more programmer friendly, but no consideration for caching, none of benefits of URIs. Trade-offs.
ReplyDeleteSophia,
ReplyDeleteI'm with Sean on this. I agree that the majority of web mapping is dishing up common variety stuff best handled with tile servers. TielMill I'm not familiar with which gathering from Jame's Fees blog, I just see as another way of generating stylized tiles (and a more use-friendly way of stylizing) similar to MapNik. Solves a different problem from what WMS does.
I also don't think WMS is just for GIS. The projection support may only be relevant for GIS, but the rest of it is useful for other things.
Imagine if you had like 20 different layers of interest - imagine how much effort that would be to create tiles for that for all the zoom levels you would need (when most of them will NEVER BE USED) - to publish that like in mapserver I just add another 5 lines of code. And of course we do have tilecaches, geocaches too which help out a bit and are best on actual use. Also at some point speed becomes less relevant with advancing CPU, GPUs technology. So thinking about speed is short-sighted and to say that just because 80% of your map need is tiles forgets about the 20% that makes your map more interesting and different from Joe Blow's down the street.
As Sean said WMS is more programmer friendly because it provides more flexibility and face it you aren't hard-coding those calls. My OpenLayers does that -- why do I give a damn what it looks like.
Sophia,
ReplyDeleteI think it is an important discussion, but I believe reports of WMS's demise are greatly exaggerated. The web is filled with really bad specifications that have become ubiquitous - HTML, JavaScript, JPG, XML, etc. The reason they stick around is not because they are any good, but because they have reached that critical mass of adoption so there is interoperability.
I have no doubt that if you control the entire stack then a different approach will deliver better performance. Often in the federal government the entire stack can not (or should not) be controlled by one implementer and there is benefit from Server A serving stuff that Application B (or C or Q) can display. WMS certainly isn't perfect, but it does support this case reasonably well.
If you have an approach for efficiently serving up tiles that everyone from ESRI to the FOSS community to the Luciad/Gallium/other-trendy-company-du-jour will agree to support in their clients, I'd love to see it. What we're finding is that in most cases, WMS is delivering acceptable performance faster than other approaches are proving interoperable. As long as this is the case, WMS will remain relevant.
Regina,
ReplyDeleteWMS (and by extension other OGC services) is a dead end not because of speed but because it does how the Internet has evolved. This Sean's point about with tile servers "you get cachability, scalability, all the goodness of URIs" — we both agree with Sean ;-).
Tiles do not have to be pre-generated, they can and are typically generated dynamically. While WMS are typically used to generate tiles, there really isn't a reason to use WMS.
The geospatial industry is moving towards deployment on cloud infrastructures along with the rest if the IT industry. This style of infrastructure favors tools that natively leverage the attributes of the internet over a protocol designed by committee.
Slar,
ReplyDeleteSince I'm on a roll, I'll venture another heresy. In practice, interoperability is a red herring. I have yet to see a production site that uses multiple web map servers that originate from different domains. The speed of a mapping client is determined by it's slowest link. If your mapping application includes a slow or frequently down WMS, chances are that people will complain or not use it. More often than not, you deploy the data yourself to ensure availability.
Getting back the "interoperability is great" world, GeoWebCache (FOSS) now serves ArcGIS tile caches. So you can use all the great ArcGIS tools to create your map and use a FOSS solution to serve it up. When it comes down to interoperability, what is more interoperable than a URL and a png?
At the risk of redundancy, Federal IT infrastructure is moving to the cloud: http://gcn.com/articles/2011/02/18/kundra-plan-25-percent-of-it-spending-on-cloud.aspx It doesn't make sense to deploy a load balanced WMS infrastructure when storage with an HTTP interface will scale for far less.
In practice the advantage of WMS is that the configuration is discoverable from a single URL from most GIS software. Usually with tile based services you need to configure the origin and resolutions yourself. I don't doubt that there are significant advantages using tiles. But it should be indistinguishable to GIS users.
ReplyDeleteAnonymous,
ReplyDeleteIn general, GetCapabilities document works well when you have less than 100 layers to serve with relatively few styles or SRS supported. I have had customers with this volume of data to serve, think federal agencies. The main problem is that the GetCapabilities document becomes too big to parse efficiently, or hold in memory, especially for web based clients. On the server side, generating this document dynamically can also take quite a bit of time and compute resources to generate. Certain implementations, such as ArcGIS, cache the GetCapabilities document and hold it in cache until ArcGIS is restarted. This works fine unless your use case requires dynamic additions to layers to the WMS.
The response to handling discovery for WMS with lots of layers has been to use a catalog. The problem is that it adds another layer of complexity that a client must negotiate. EBRIM much?
In contrast, tile servers are dead simple. Tile size can specified and resolutions are set both dejuré and defacto. There is no handshake, no processing of XML, you just get maps. Of course you have to know apriori what you are requesting, but in practice do you really know what you are getting when you select a layer in a WMS?
I been in GIS App development for over three years now and I did'nt have opportunity to work with WMS as they SUCK..You are right Sophia. I worked with all kind of geospatial developer and know tons of real world geo spatial application, among all those share of WMS is negligible. People who are crying about it are same people who cried for arcIMS but its gone too.
ReplyDeleteIf anyone has doubt, just Google the Web App and see who is using WMS...
I'm not sure how to find out who is using WMS in their applications, but there is quite a bit of data served through WMS. For example, there are 14K WMS layers listed at the FGDC monitoring site: http://registry.fgdc.gov/statuschecker/wmsResultsReport.php
ReplyDeleteI'm sure that there are more catalogs of WMS services out there if you search for "GeoNetwork". I agree with you about adoption/use, despite the number of of WMS services and layers available, I have yet to see actual usage numbers. This is what I mean about the long tail of WMS.
INSPIRE viewservice dictates WMS on steroids (WMS will learn to speak all the European languages) and WMS has evolved so it now does tilecaches (WMS-C/WMTS) as well.
ReplyDeleteoh yeah, we also want to support 20 or so different SRS's
mc.prins,
ReplyDeleteThat's great but if the INSPIRE viewer (http://www.inspire-geoportal.eu/index.cfm/pageid/341) is any indication of performance, the 20-30 second load times is not very inspiring.
I think the saying that a map service can be either be fast or interoperable, but not both is not true. It's a matter of picking the right technology and architecture.
With something like this, there are three categories of interoperability.
ReplyDelete1. Adopted standards. Things like WMS give almost complete interoperability but sometimes you feel like you are trying to pound a round peg into a square hole.
2. Emerging standards. You get better performance, but you usually have to do some development to get there. Tile servers fit into this category - they are more or less standardized but most vendors haven't implemented support yet. If you have full control over the solution, it's fine. The FOSS community tries to inhabit this space at every opportunity.
3. Proprietary solutions. Customers will often sacrifice interoperability if they find a solution that is performant and requires minimal development.
The problem I'm having with the Army is that it moves at glacial speeds. If I suggest Door #2 the response is "Sounds good. We can field that by 2017. So...what would you like us to do until then? Unless you have a better plan, I'm just going to pick Door #3." Therefore I am often stuck promoting Door #1 and hoping that it isn't the weakest link in the system. (That's usually when ESRI pipes up and says "Don't worry, we'll be sure to break something so that we can justify our expensive maintenance agreement.") I don't see this changing any time soon so I don't see WMS going anywhere.
In the meantime, please stand up a WMS so that I can at least see your data, even if I'm ultimately going to want to acquire it and host it myself.
The INSPIRE legislation has fairly strict requirements on performance (response time for 800x600 pixels, 8 bits==470Kb image is =< 5 sec.) and availability (99%). Just because some proof of concept viewer makes 20 or so 15KB requests for a layer (instead of one) doesn't make the services slow, it just demonstrates a poor use of the requirements.
ReplyDeleteSlar,
ReplyDeleteI concur with everything you have said. I've also been in the same situation selling WMS as a solution. We often would make a sale as a "special project" , i.e. it's an experiment. It was frustrating that it was difficult to get anything into production and customers would default to Option 3.
However, I don't believe that WMS is the only way to make web maps discoverable. A simple README or metadata document of your choice at the root of a tile cache would suffice. The best part of this is that this can be indexed by crawlers instead of having to do the GetCapabilities two step dance to get an ISO19115 doc that may point to actual metadata buried in an ISO 19139 doc.
If we really wanted to get fancy, metadata can be embedded in the tiles as EXIF for jpgs or XMP for pngs.
Of course there is also the WMS-C or WMTS spec, but again you have to deal with a service interface that I feel is overly complicated.
mc.prins,
ReplyDeleteThat's the problem with legislated requirements, people end up building systems that only meets the minimum. I'll be bold and predict that by 2015 INSPIRE requirements will be OBE as well, which is well before the 2019 end date for implementation.
sophia
Interesting discussion. Just wondering why people bash the getCapabilities document with comments like:
ReplyDelete"In contrast, tile servers are dead simple. Tile size can specified and resolutions are set both dejuré and defacto. There is no handshake, no processing of XML, you just get maps. Of course you have to know apriori what you are requesting, but in practice do you really know what you are getting when you select a layer in a WMS? "
So you are saying that the tile-request is simpler because you have to lookup the format of the url beforehand and then make the request?
What's stopping you from doing exactly the same thing with a WMS?
The only difference I see between the two approaches you've described is the shorter url for the tileserver. (And the fact that there is no standardized way of obtaining the url format for the tileserver)