[OSGeo-Standards] Re: [WMS.RWG] Let's talk about OSGEO tiled solutions and try to integrate them in WMS and WMTS documents.

[Arnulf Christl]

http://portal.opengeospatial.org/twiki/bin/view/WMSrwg/TilingSupportAdd

Disclaimer: Authorization Required
This mail could not verify that you are authorized to access the information contained. Either you supplied the wrong credentials (e.g., bad password), or your mail client doesn't understand how to supply the credentials required.



Hello, 
I forward this email to OAB because I like Keith's thoughtful tone and it fits in with some of the ideas about elephants, trunks, tails culture clashes and the big picture in yesterday's OAB call. 

Find more comments at the end.

Keith Pomakis wrote:
> Joan Maso wrote:
>> It seems that there is a general feeling that this working group is
>> ignoring OSGEO aproach to the problem. Let me remember that
>> we review this aproach in
>> http://portal.opengeospatial.org/wiki/twiki/bin/view/WMSrwg/TilingSupportAdd
>> (07/06/2007).  Anyway. We have to work more in OSGEO proposals in order to
>> better integrate their efforts on the actual solutions. Let me iniciate
>> the debate:
>>
>> In fact, it seems that there are 2 OSGEO different approaches to this
>> issue.  One of them suggests only limitations on conventional WMS spec.
>> http://wiki.osgeo.org/index.php/WMS_Tile_Caching#WMS-C_as_WMS_Profile
>>
>> The other is the REST aproximation that was mention in a recent email
>> to WMS.RWG mail list:
>> http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification
> 
> I'm familiar with both of OSGeo's approaches to WMS tiling, and
> gave their approaches considerable attention when trying to define
> the approach proposed by 07-057r3.  Perhaps I should have included a
> section in 07-057r3 which discusses the OSGeo approaches and compares
> and contrasts them with the WMTS proposal.
> 
>> Lets talk about both proposals:
>> "to limitations on conventional WMS spec"
>> This could be very easy to bring this aproach to the next WMS spec as a
>> profile because thay propose a clear list of limitations. We can add an
>> annex on next WMS document describing this list of restrictions
> 
> I agree that this approach could easily and comfortably take the form of
> a WMS profile if there's enough interest in it.  I didn't include this
> approach at all in the 07-057r3 WMTS proposal specifically because I do
> see it as more of a WMS profile than as its own specification.
> 
> I can see this approach co-existing with the WMTS approach because they
> fulfil two different requirements.  The requirement that this approach
> fulfils, in essence, is to define a way of adapting a WMS (which is very
> flexible in what it can return at the expense of speed, having to (in
> general) render requested maps on the fly) so that it can effectively be
> used by tiling clients (that require very fast and efficient responses).
> 
> This mechanism can certainly serve as a temporary bridge between the two
> paradigms (full-WMS versus tiling), and in some environments where WMS
> servers are already employed it may suffice as a long-term solution.
> However, I don't believe it's a great long-term solution to WMS
> tiling in general.  Having a complex server that can render maps on
> the fly as an inner part of a mechanism that has no such requirement
> is not an ideal situation.  That is, recommending the implementation
> of a full WMS for the sole purpose of wrapping a TileCache around so
> that the server can be utilized as a tile server is asking too much.
> Thus, there still exists a need to design a server specification whose
> protocols are specifically intended for serving pre-rendered tiles.
> 
> Put another way, there will likely be many tile servers implemented
> and brought into production in the future.  Since a request for a tile
> (the fundamental operation of a tile server) is essentially a request for
> static content, there should exist a server solution that doesn't require
> the implementation of a server that is required to generate dynamic
> content.  Hence the WMTS effort (and the REST-style OSGO approach).
> 
>> "REST aproximation"
>> This seems more complicated to me. The natural way integrate this aproach
>> is to expand 07-057r3 in order to include a REST profile. I do not know
>> any previous OGC standard based on REST so it could be a new adventure.
>> Also, we have to review both documents and be sure that any detail
>> in OSGEO proposals is covered by 07-057 document.
>>
>> What do you think?
> 
> I have to admit that I like this OSGeo proposal a lot.
> After spending the last few years immersed in OGC
> specifications, I found the OSGeo proposal (located at
> "http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification")
> to be a breath of fresh air.  I saw a few areas of the specification
> where I think things need to be specified a bit more tightly in order
> TO GUARANtee interoperability, and I think a couple of things need to
> be added (e.g., the concept of styles), but overall I was impressed
> with the simplicity of the approach.  I think it technically breaks the
> principles of REST a bit by requiring the client to construct the last
> part of the URL of a tile (i.e., filling in the tile row, tile column
> and filename extension), but I think this is a perfectly acceptable
> compromise for the sake of simplicity and efficiency.
> 
> However, the biggest problem I see with it, from OGC's point of
> view, is that it doesn't do things the OGC way.  All of the OGC
> services to date have been entrenched in a particular paradigm (e.g.,
> SERVICE=whatever&REQUEST=whatever, etc.).  The requests that OGC clients
> make of OGC servers are akin to function calls (with the request type
> (e.g., "GetMap") being the function name and the other key-value pairs
> being the parameters of the function).  Whether or not this is the
> best way of doing things is mostly moot at this point; it's simply,
> at present, the OGC way of doing things.  There are a number of OGC
> documents that have been defined over the last few years, with more
> under active development, that more and more clearly and fully specify
> this OGC way of doing things.  Many of these documents dictate how OGC
> servers SHALL behave.
> 
> The REST approach of the OSGeo proposal, however elegant, is incompatible
> with much of the OGC way of doing things.  I believe it would be against
> several core OGC web service policies to define a service behaved in a
> way that isn't compliant to, for example, the OWS Common Implementation
> Specification.  And I think that's a good thing; it would probably
> be a very bad idea to define a rogue service that wasn't compliant in
> these ways.  One of the main reasons for defining things like the OWS
> Common Implementation Specification is to allow reuse of mechanisms and
> data structures, etc., between services so that they can be smoothly
> integrated and so that a single core set of libraries can be utilized in
> the implementation of several services (rather than having a completely
> separate and redundant code base for each service).
> 
> Given this, if the OGC were to attempt to define a web-map tiling
> service that was based on the REST approach, it would necessarily
> involve introducing many (quite likely controversial) changes and/or
> additions to some of the core OGC specifications that dictate the "OGC
> way of doing things".  "A new adventure" indeed.  It would take years
> and require the involvement of several OGC core groups.  And then we'd
> end up with some specifications that use the KVP function-call-style
> approach, and some specifications that use the REST approach, making
> them more difficult to integrate - in other words, blowing the whole
> reason for having core specifications to begin with.
> 
> So the question becomes this: Is it feasible to define a web-map
> tiling approach that does things in the OGC way (such as the WMTS
> proposal), that includes an alternative RESTful way of doing things
> (such as the OSGeo proposal)?  In other words, would the advantages
> gained by defining alternative interfaces outweigh the disadvantages
> of complicating and convoluting the specification as necessary to allow
> the choice of interface?
> 
> My feeling is that the answer to this question is "no".  I think
> the two approaches are different enough that it would largely split
> the specification into two mutually exclusive parts: "the OGC-style
> approach" and "the RESTful approach", with only a small fraction of the
> specification being relevant to both approaches.  I think if we were
> to conclude that this would be the result, then it would be better just
> to stick with two separate specifications - the OGC WMTS specification
> and the OSGeo Tile Map Service specification.
> 
> It was with all this in mind that I set out to define the WMTS approach
> in 07-057r3.  I've tried to keep the WMTS approach as simple and elegant
> as possible while still fitting into the framework of the "OGC way of
> doing things".
> 
> In summary, it seems to me that the three different approaches that
> we've been discussing each have strong and valid reasons for existing
> (the 07-057r3 WMTS approach for its compatibility with other OGC
> services and in general with the "OGC way of doing things"; the OSGeo
> WMS profile approach for its power to adapt existing WMS services to
> be able to efficiently serve tiles; and the OSGeo RESTful approach
> for its simplicity).  But this leaves us in a bit of a quandary.
> If each of these three different server approaches were to evolve into
> industry-standard specifications, it would require three different types
> of client implementation to handle them all, which certainly isn't an
> ideal situation.  But at this point I'm thinking that this might be
> something the industry has to endure, at least for a while.  In five
> years time things might be different; it may be much more obvious to
> us then which single approach is the superior one (or perhaps which
> has become the more popular one - not necessarily the same thing!).
> But for now I see little choice but to separately develop and experiment
> with all three approaches.
> 
> Comments?  Opinions?
> 
> .-------------------------------------------+-------------------------------.
> | Keith Pomakis                             | E-mail: pomakis at cubewerx.com  |
> | Senior Software Developer, CubeWerx Inc.  | Phone:  (819) 771-8303 x204   |
> | 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    (819) 771-8388        |
> `---------------------------------------------------------------------------'
> _______________________________________________
> WMS.RWG mailing list
> WMS.RWG at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wms.rwg

The phrase "the OGC way (of doing things)" is mentioned four times as if it were some fixed unchangeable well defined law. The very first sentence on the OGC web site http://www.ogcnetwork.net/ reads something different (and imo more appropriate): 

"OGC Network™ is a window onto the dynamic, constantly changing geospatial web as described by the OpenGIS® Reference Model (ORM). Multiple communities of interest for research in geospatial interoperability are supported, and persistent demonstration capability is provided."

I myself have been in GIS way too long to not think that it is the most important bit in the world. But I do remember setting up web services in my role as UNIX administrator in the early nineties and way back then the http-way of doing things was already well defined and was about to rid all other protocols from the Web. REST was on its way but without anybody knowing. What I want to say with this is that we should be humble in our perspective of what exactly the weight and relevance of "the OGC way (of doing things)" to the real world really is. Don't get me wrong, I do not want to belittle OGC or its achievements but I do think that we should consider staying tuned to the REST of the world if we really want to be(come) ((or even stay)) The Spatial Standards org.

Quoting Keith:
> Whether or not this is the
> best way of doing things is mostly moot at this point; it's simply,
> at present, the OGC way of doing things.

Ah - but then we are not consensus and not open and not up-to-date but an old, dying religion (polemics for emphasis reasons only). 

> The REST approach of the OSGeo proposal, however elegant, is incompatible
> with much of the OGC way of doing things. 

Step back, reword, take the outside perspective: 

"The approach of the OGC proposal, however streamlined to OGC ways of doing things,
is incompatible with much of the REST of the world."

This is not half as outlandish as it might feel at first. There are loads of quotes (for example by crschmidt, one of our FOSS icons) talking about "OGC land". This has to be avoided! We are not in OGC to build a fence to the rest of the world but to give the rest of the worlds standards that work for them (I drop capitalizing REST all the way...).

> between services so that they can be smoothly
> integrated and so that a single core set of libraries can be utilized in
> the implementation of several services (rather than having a completely
> separate and redundant code base for each service).

This is a narrow approach in that it suggests that all libraries should be good for all OGC specs. I do not think so, this is the danger of standards preventing innovation. 

> then it would be better just
> to stick with two separate specifications - the OGC WMTS specification
> and the OSGeo Tile Map Service specification.

But OSGeo is not a standards body and does not plan to become one. At least I personally spent quite a lot of arguments on mailing list, IRC and f2f meetings when these ideas came up in OSGeo and tried to make sure that OGC is the body (and maybe OSGeo puts in some brains and reality - sorry for the pun, I never really mean things like I say them... :-)

Last but not lease I think that to understand the cultural problem put forward by John could it will help to reread The Bazaar. Not that I concur with ESR but it does give some insights and is good for a reread every now and then. 
http://catb.org/~esr/writings/cathedral-bazaar/

And then - I just simply cannot refrain from saying this - hacking software should be fun. Apply the same to standards. We are not fighting things but creating things. 

Best regards, 
Arnulf.