[Requests] Comments for 07-057r6, Candidate OpenGIS Web Map Tiling Service Implementation

Plesea, Lucian lucian.plesea at jpl.nasa.gov
Sun Apr 5 23:04:31 EDT 2009


Part A

1 Evaluator

Lucian Plesea, Caltech/JPL/NASA

2 Submission:
Comments for
OGC 07-057r6, Candidate OpenGIS Web Map Tiling Service Implementation

Part B

General comments:

The WMST is an impressive proposal, with many good features.  I particularly like the use of the top-left reference, which allows implementation of local high resolution insets.
I believe it still has many problems to be addressed.


1 Requirement

Without disagreeing with the conclusion that an API that exposes pre-existing tile sets is needed, the introduction claims that WMS does not scale and that caching does not help.  This is simply wrong and in contradiction to my experience. Caching WMS does improve performance in most cases.
The WMS protocol, when combined with caching, scales very well.

2 Section Number: Introduction, page xi

3 Criticality: Major

4 Comments:

In reality, caching a WMS server greatly improves performance in most cases, at least in a public environment.
Most applications that make WMS requests tend to issue grided requests, which respond extremely well to caching.
The only applications that do not repeat requests are simplistic human-in-the-loop viewers and WMS benchmark applications.  Scalability is not a big issue in the first case, and the second case is not relevant to real use.
Any potential WMST client by definition will also be very responsive to caching.
For example, implementing caching for WorldWind requests reduced the load by two orders of magnitude in less than three days while improving the response time seen by users.
The Onearth WMS implementation more than proves that WMS itself as an interface protocol is extremely scalable and fast when used with preexisting tiles.  Thus, in the OnEarth server WMS tiled implementation, the API used is not the limiting factor.
This server has proven capable of serving more than 200 requests per second even from a regular laptop.  This transaction rate is close to the disk seek time, a limit which will exist in any large scale tile server, WMST or otherwise.

1. Requirement

WMST should allow multi-layer requests

2 Section: 6, Overview

3. Criticality: Significant

4. Comments:

The lack of multi-layer requests makes it much harder to implement a user friendly client.  Multilayer requests where added in WMS 1.1.1 exactly for this reason, why exactly these are not supported in WMST?  Why should GoogleMaps like "hybrid" views be impossible to implement in WMST?
The difference between the mandatory WMS parameter "layers" and the proposed mandatory WMST parameter "layer" is confusing.
The requirement that the client only implements the overlay for maps in onerous, considering that the need for WMST is partially predicated on a simpler client.

1. Requirement:

The math on page 9 is wrong and should be eliminated.

2 Section: 6.1

3 Criticality: Major

4 Comments:

The math on page 9 fails when (bBoxMinX-tileMatrixMinX)/tileWidth=N +- epsilon, in which case
the explicit addition of "epsilon" leads to an error in computing the column/row values.
Why is "epsilon" rounding needed here?

1. Requirement:

Define crsx and crsy

2 Section 6

3 Criticality: Major

4 Comments

crsX and crsY are not well defined.  Are they defined anywhere else in OGC?  Why not use pixel coordinates for the top-left corner of the tile instead of tile indices.
This seems much more natural given the raster nature of the tiled data, and eliminates confusing math (see above).

1 Requirement:

Define "accepted formats" in Table 2

2 Table 2

3 Criticality: ?

4 Comments:

What are the "accepted formats" referenced in Table 2?

1 Requirement:

Provide examples for use of WMST for planetary data

2 Location: Table 8

3 Criticality: Major

4 Comments

Alternatives to WGS84 when data is from a different planet should be provided, to avoid mixing earth and non-earth maps.
See http://www.lpi.usra.edu/meetings/lpsc2006/pdf/1931.pdf

1 Requirement

Allow non-square pixels

2 Location: NOTE on page 9

3 Criticality: Minor

4 Comments
The existing globe viewers that use WGS84 tiles (GoogleEarth and WorldWind) look much better with non-square pixels close to the poles.


1 Requirement

TileMatrixSets needs hierarchy, probably more than "layers".

2 Location: Table 14

3 Criticality: Major

4 Comments

Grouping TileMatrixSets can provide information about how the sets are meant to be used, in case different TileMatrixSets are available for the same layer.

1 Requirement:
Refine RESTfull implementation by using KML.

2 Location: NA

3 Criticality: Major

4 Comments
Allow KML as a return type.  Using the superoverlay feature of KML, TileMatrixSets are self-defined.
This would also allow choosing the format of a type independent for each tile, optimizing the use of data.  Also, explicit leaf nodes can be implemented.

1 Requirement:
Allow WMS as an alternate request style

2 Location: NA

3 Criticality: Major

4 Comments

Tiled WMS has already proven functional by the OnEarth WMS server and the many clients that support it (GoogleEarth, WorldKit, WorldWind, FlashEarth ...).
This type of requests should be integrated in WMST.  The main benefit is a much simpler transition from WMS to WMST, simply by implementing a cache, which can then be exposed using the WMST protocol for use by other WMST clients.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opengeospatial.org/pipermail/requests/attachments/20090405/8e321266/attachment.htm 


More information about the Requests mailing list