Resource tree Resource folder

26 Copyright © 2012 Open Geospatial Consortium.

6.6.2 scaleDenominator

An alternative to provide the width and height is to just provide a nominal scale denominator. In fact this is another way to reconcile the pixel space and the CRS. This approach avoids mentioning the size of the screen by just providing an initial scale for the context document. An integrated client that is initially empty, can start with that scale denominator and if there is a WMTS description the client can start requesting with a list of tiles. When the client view is too small, the client can simply ignore the unneeded tiles and when the view is too big, the client if knowledgeable enough can generate new tile URLs for the missing tiles or else leave them blank. A client is still able to present the information, make overlaps and transform between pixel space and CRS coordinates using the initial scale, it is also able to perform very simple mathematics even if the client does not parseunderstand the OGC requests.

6.7 Resource ordering and grouping

6.7.1 Resource displaying ordering

The use of Atom encoding is not giving the entries any particular ordering. Experience says that some clients may choose to order the entries in reverse chronological order via: atom:published or atom:updated. That is, the most recently published or updated entries are shown at the top of the list of syndication headlines. After some discussions, it has been agreed that the order of the resources in the context document will be the order of the screen presentation, assuming that the first resource will be presented on top of the others.

6.7.2 Resource grouping

We have been speculating about different alternatives to group resources in a tree structure. At the time of writing this report, it seems that the Resource folder alternative will be finally adopted.

6.7.2.1 Resource tree

An obvious way to do this is by allowing the resources to be contained within another resource in a recursive way. The parent resource acts as a folder that can have several children. This conceptual model is the one suggested in OWS Common. Unfortunately, the main expected encoding XML Atom does not allow nesting entries. This is the reason why we discarded it.

6.7.2.2 Resource folder

Add a “folder” property to a resource. A “” delimits a folder path for the resource. If a folder is not specified or empty the layer is not placed in a folder. Copyright © 2012 Open Geospatial Consortium. 27 The folder specifies a default ‘tree’ organization for a resource; this is intended to allow resources to be grouped. If the folder is empty then the resource exists at the root level. If a folder is specified the resource is placed in the folder. For example: Resource: title: “VectorMap1”, Folder: “Background Maps” Resource: title: “VectorMap2”, Folder: “Background Maps” Resource: title: “Roads”, Folder: “TransportationLand” Resource: title: “Railways”, Folder: “TransportationLand” Resource: title “Rivers”, Folder: “TransportationWater” Resource: title “Canals”, Folder: “TransportationWater” Resource: title “Annotation”, Folder: “” This will be interpreted by the client as follows: Note, in order to comply with the ordering rules for resources, all resources with a given folder must be grouped together. Hence the following is invalid: Resource: title: “VectorMap1”, Folder: “Background Maps” Resource: title: “Roads”, Folder: “TransportationLand” Resource: title: “VectorMap2”, Folder: “Background Maps” This is because you cannot put Roads between Vector Map 1 and Vector Map 2 without it being in the same folder. Recent debates indicate that this could be the final selected option.

6.7.2.3 Resource themes