100
Marian de Vries and Peter van Oosterom
Initial Requests
When the Web client requests the data at one specific importance level (e.g. 101) the
query to the database would be something like this:
select face_id as id, ’101’ as impLevel,
RETURN_POLYGON(face_id, 101) as geom
from tgapface
where imp_low <= 101 and 101 < imp_high
This query will retrieve polygons from the database (constructed dynamically
by the RETURN POLYGON function). The result is one ‘slice’ of the data set at a
specific importance level. The disadvantage is that all objects have to be visualized
at once (to get a complete map without holes), progressive transfer is not possible,
and the GAP-tree structure is not ‘rebuilt’ at the client for smooth zooming later on.
The next query will also retrieve polygons from the database, but now not one slice,
but a range of objects from the most important level until a certain importance level
(e.g. 90), sorted in order of importance (descending from high to low):
select face_id as id, imp_low, imp_high,
RETURN_POLYGON(face_id,imp_high-1) as geom
from tgapface
where imp_high > 90
order by imp_high desc
Note no upper boundary of the required importance is specified, only a lower boundary of ‘90.’ This means that everything starting above 90 and up to the root importance will be selected. When the WFS service receives the results from the data layer
the data is already in the right importance order (from high importance to low importance) and can be passed to the client (as GML) in that same order. When the client
receives the GML, there are three possibilities that differ with respect to the moment
that the data is visualized as map:
a. Rendering in small steps. The client software already starts visualizing parts of
the incoming GML data before the whole data stream is received. Here we have
an example of ‘true’ progressive transfer. The objects are received and visualized
in sets of two objects which replace one parent at a time (see Sect. 5.2, binary
GAP-face tree). The map is progressively rendered in small steps. The visualization is very smooth: the user first sees the contours and then slowly the details
are filled in (see screenshots in Fig. 5.12).
b. Visualize the incoming GML in two or more larger steps, refreshing the complete spatial extent that is displayed in the map after a certain time interval (of 2
seconds for example). In this case the client will at given times visualize the level
of the latest objects it has received. Here also the data is in the right importance
order so that progressive refinement/generalization in the later stages is possible,
only the refresh is done for the whole area.
Marian de Vries and Peter van Oosterom
Initial Requests
When the Web client requests the data at one specific importance level (e.g. 101) the
query to the database would be something like this:
select face_id as id, ’101’ as impLevel,
RETURN_POLYGON(face_id, 101) as geom
from tgapface
where imp_low <= 101 and 101 < imp_high
This query will retrieve polygons from the database (constructed dynamically
by the RETURN POLYGON function). The result is one ‘slice’ of the data set at a
specific importance level. The disadvantage is that all objects have to be visualized
at once (to get a complete map without holes), progressive transfer is not possible,
and the GAP-tree structure is not ‘rebuilt’ at the client for smooth zooming later on.
The next query will also retrieve polygons from the database, but now not one slice,
but a range of objects from the most important level until a certain importance level
(e.g. 90), sorted in order of importance (descending from high to low):
select face_id as id, imp_low, imp_high,
RETURN_POLYGON(face_id,imp_high-1) as geom
from tgapface
where imp_high > 90
order by imp_high desc
Note no upper boundary of the required importance is specified, only a lower boundary of ‘90.’ This means that everything starting above 90 and up to the root importance will be selected. When the WFS service receives the results from the data layer
the data is already in the right importance order (from high importance to low importance) and can be passed to the client (as GML) in that same order. When the client
receives the GML, there are three possibilities that differ with respect to the moment
that the data is visualized as map:
a. Rendering in small steps. The client software already starts visualizing parts of
the incoming GML data before the whole data stream is received. Here we have
an example of ‘true’ progressive transfer. The objects are received and visualized
in sets of two objects which replace one parent at a time (see Sect. 5.2, binary
GAP-face tree). The map is progressively rendered in small steps. The visualization is very smooth: the user first sees the contours and then slowly the details
are filled in (see screenshots in Fig. 5.12).
b. Visualize the incoming GML in two or more larger steps, refreshing the complete spatial extent that is displayed in the map after a certain time interval (of 2
seconds for example). In this case the client will at given times visualize the level
of the latest objects it has received. Here also the data is in the right importance
order so that progressive refinement/generalization in the later stages is possible,
only the refresh is done for the whole area.