102
Marian de Vries and Peter van Oosterom
on event handling. When the GML data is visualized using SVG (scalable vector
graphics) for example, the ‘onzoom’ event of the SVG DOM can be used.
When a new GetFeature request is necessary, the scenario is partly the same as
in the previous case: first the right importance range for the new objects has to be
calculated. The second step is then to request the new objects (only the ones that are
not yet already in the client).
Finding out whether or not a new request is necessary implies that the client
software should not only keep track of the spatial extent of the already received data,
but also of the importance range(s) of these objects.
An issue for further research is how to calculate the right importance range for
the ‘new’ set of objects to be displayed. The algorithm will have to be a function of
the size of the map window (in pixels), the zooming factor for that particular zoom
action, and some kind of optimal number of objects for that map size. To establish
the optimal number of objects a straightforward rule of thumb could be “an optimal
screen has a constant information density: so keep on adding objects with a lower
importance until the specified number of objects is reached; for example 1000.”
An alternative could be applying T¨ opfer’s Radical Law: n f = n a C
(M a /M f ) x
where “n f is the number of objects which can be shown at the derived scale, n a is the
number of objects shown on the source material, M a is the scale denominator of the
source map, M f is the scale denominator of the derived map” [19]. The exponent ‘x’
depends on the symbol types (1 for point symbols, 2 for line symbols and 3 for area
symbols) and ‘C’ is a constant depending on the nature of the data (an often used
value is 1).
5.5.2 Extensions to OGC/ISO Standards?
Are extensions of the existing OGC WFS protocol necessary for the progressive
transfer and refinement scenarios described in the previous paragraph? The first
option is to use the existing GetFeature request and specify the importance range
(imp low, imp high) as selection criteria in the Filter part of the request. And using
the ogc:SortBy clause that is available since WFS version 1.1 the client can instruct
the WFS service to return the objects in order of importance.
Still this is not an ideal solution. Somehow the Web service has to communicate
to the client that it supports progressive transfer and refinement. The self-describing
nature of the OGC WFS GetCapabilities response is an important part of creating
interoperable service/client solutions. For the WFS protocol this means that somewhere in the GetCapabilities document it must be stated that this particular WFS
server can send the objects sorted in order of importance. Another addition to the
WFS Capabilities content is reporting the available importance range (imp low –
imp high) of each feature type, comparable to the way the maximum spatial extent
(in lat/long) of each feature type is given in the GetCapabilities response. For this
reason (to supply solid service metadata that clearly state the capabilities of the service) it would be better to add a new request type to the WFS protocol, for example
with the name GetFeatureByImportance. Just like there is, besides the Basic WFS,
also a WFS-T (transactional WFS) with extra requests for editing via a Web service,
Marian de Vries and Peter van Oosterom
on event handling. When the GML data is visualized using SVG (scalable vector
graphics) for example, the ‘onzoom’ event of the SVG DOM can be used.
When a new GetFeature request is necessary, the scenario is partly the same as
in the previous case: first the right importance range for the new objects has to be
calculated. The second step is then to request the new objects (only the ones that are
not yet already in the client).
Finding out whether or not a new request is necessary implies that the client
software should not only keep track of the spatial extent of the already received data,
but also of the importance range(s) of these objects.
An issue for further research is how to calculate the right importance range for
the ‘new’ set of objects to be displayed. The algorithm will have to be a function of
the size of the map window (in pixels), the zooming factor for that particular zoom
action, and some kind of optimal number of objects for that map size. To establish
the optimal number of objects a straightforward rule of thumb could be “an optimal
screen has a constant information density: so keep on adding objects with a lower
importance until the specified number of objects is reached; for example 1000.”
An alternative could be applying T¨ opfer’s Radical Law: n f = n a C
(M a /M f ) x
where “n f is the number of objects which can be shown at the derived scale, n a is the
number of objects shown on the source material, M a is the scale denominator of the
source map, M f is the scale denominator of the derived map” [19]. The exponent ‘x’
depends on the symbol types (1 for point symbols, 2 for line symbols and 3 for area
symbols) and ‘C’ is a constant depending on the nature of the data (an often used
value is 1).
5.5.2 Extensions to OGC/ISO Standards?
Are extensions of the existing OGC WFS protocol necessary for the progressive
transfer and refinement scenarios described in the previous paragraph? The first
option is to use the existing GetFeature request and specify the importance range
(imp low, imp high) as selection criteria in the Filter part of the request. And using
the ogc:SortBy clause that is available since WFS version 1.1 the client can instruct
the WFS service to return the objects in order of importance.
Still this is not an ideal solution. Somehow the Web service has to communicate
to the client that it supports progressive transfer and refinement. The self-describing
nature of the OGC WFS GetCapabilities response is an important part of creating
interoperable service/client solutions. For the WFS protocol this means that somewhere in the GetCapabilities document it must be stated that this particular WFS
server can send the objects sorted in order of importance. Another addition to the
WFS Capabilities content is reporting the available importance range (imp low –
imp high) of each feature type, comparable to the way the maximum spatial extent
(in lat/long) of each feature type is given in the GetCapabilities response. For this
reason (to supply solid service metadata that clearly state the capabilities of the service) it would be better to add a new request type to the WFS protocol, for example
with the name GetFeatureByImportance. Just like there is, besides the Basic WFS,
also a WFS-T (transactional WFS) with extra requests for editing via a Web service,