Granularity is often ignored when designing geospatial Web services. Choices relating to granularity affect service interfaces, data storage and organization, and XML format design. This chapter highlights the importance of analyzing usage and performance requirements when deciding on granularity choices in the design of geospatial Web services. Often, instead of making design decisions based on these requirements, geospatial services are implemented using default, commonly used techniques which may reduce performance, increase complexity, or fail to fully meet user needs. This chapter discusses the importance of granularity in designing and implementing geospatial Web services and provides common examples that highlight the different approaches to granularity which are available.
TopIntroduction
A common issue in the design of enterprise class geospatial Web services is that of granularity. Granularity refers to the fineness in which services and data are divided. For example, consider a mapping service which provides road data. If coarsely defined, the service might just provide a single layer titled “Roads.” This single layer makes the service easy to use for the average user. Alternatively, a GIS analyst may prefer to have the road data sub-divided into several layers, each representing different types of roads. The increased granularity provides technical benefits to the power user that a layperson would not value, all at additional cost to the computational requirements of the service.
There is no rule of thumb for the right amount of granularity to provide in the design of geospatial Web services. An analysis of the tradeoffs associated with different levels of granularity must be performed on a case-by-case basis. This analysis is necessary not only in the design of geospatial service data groupings, but also in the underlying storage of data and the XML encoding used for sharing data. A parallel exists in the design of database indexes. There is no one-size-fits-all index which will universally increase the performance of all queries for every dataset. Careful study must be made of a variety of parameters such as query frequencies, computational load, and result set sizes before an optimal indexing scheme may be chosen (Lewis 2001). Too often granularity is ignored as a design choice when creating geospatial services, leading to increased costs and decreased functionality when the service is deployed.
This chapter will outline the general issues relating to granularity in the design and deployment of geospatial web services. It will provide a discussion and analysis of the impact of granularity on three principal issues:
- 1.
Design of external interfaces for geospatial Web services
- 2.
Storage and organization of the underlying geospatial data
- 3.
Encoding of geospatial data in XML formats
The primary focus of the chapter will be the Open Geospatial Consortium (OGC) collection of geospatial service standards (OGC 2010). OGC services provide few highly structured access patterns that should be used to motivate the design of geospatial data storage systems and retrieval services.
TopBackground
Granularity in geospatial data is often dealt with as a resolution issue (Robinson et al. 1995). In mapping terms, resolution refers to the level of detail or accuracy of a data set. For example, satellite imagery can have pixel resolutions of anywhere from 500 meters per pixel to under 1 meter per pixel. Additionally, paper maps often have a nominal scale, like 1:10,000 or 1:100,000. In the context of map scale, granularity is a major issue. A paper map of a large area, like a state, might only depict major roads and larger cities, while a map of single city would include streets, alleys, parks and playgrounds. Within digital mapping, data sets are often designed with multiple scales. For example, a data set of roads at the 1:100,000 scale, might depict a road’s path with 50 vertices, while the 1:10,000 version of the same road path might use 500 vertices. Consider the road paths shown in Figure 1. Both polylines represent the same path at different resolutions. The top path uses many more vertices than the bottom path. One might ask, why would the lower resolution bottom path ever be used, if a higher resolution version was available. First, the lower resolution path requires less storage space, allowing it to be retrieved and sent to user much faster. Additionally if both of these paths were viewed at a lower scale view, for example 1:100,000, they would look exactly the same. It is only at the higher scale view, 1:10,000, where their differences are apparent. Figure 2 shows the same two paths, but at a lower scale view. In this view, the differences between the paths are less visible.
Figure 1. Two depictions of the same road path at different resolutions
Figure 2. Small scale version of the two resolutions of the same road path