MapViewSVG is situated in the low cost application area and is best suitable for smaller projects.

Within the SVG mapping project, different GIS functionalities and types of tasks are implemented like:  

Mapping and visualization

Supporting symbols and labels, turning on and off individual layers, providing legend, overview map, and other site information, displaying layers at certain scales.

Navigating with maps

Zooming, panning, setting the map scale, providing spatial bookmarks and scale bar.

Interacting with maps

E. g. Identifying features on the map, hyperlinking, map tips, measuring distances, coordinate read-out, selecting features by attributes (query builder), statistics, and other visualization of data (graphs, charts, and attribute tables including the linking to the features on the map).

Creating and manipulating of features and data

Primarily, these functions are not implemented in MapViewSVG, and need further customization (see chap. 7).

The size of GIS/SVG data gets very large. The increasing loading time of the SVG files within the browser has to be seen as a limit. The whole application looses its practicability. To overcome this (general) disadvantage of SVG files (especially when displaying images), we developed a tool, which cuts the layer (raster, line or point layer) into several tiles. The specific tiles will be loaded dynamically (via XMLHttpRequest) as soon as they are visible within the map extent.

Also generalization tools, provided by ArcGIS (generalizing with the Douglas-Poiker algorithm, smoothing by converting the geometry as Bézier curves), are used to simplify polygon or line features.

In general, we would appreciate methods to indicate the state of loading to the user (e.g. wait cursor, progress bar).

While many of those symbols can be easily converted to SVG, there exist a few which can be converted only using tricks (but then with lack of practicability or a performance loss) or can’t be converted at all. For example:

Irregular pattern / dot density rendering

Dot density maps represent quantitative data by drawing randomly placed dots inside polygon features (Fig. 3). Also irregular pattern is often used for map design. So far there is no equivalence in SVG.

Multi lines with line offset

Multi lines can be created by defining a path and referencing on it with the “use” element. Each use element has its own width, colour and pattern of dashes and gaps. With these attributes you can define most multi lines with perfect quality. But unfortunately there is missing a line offset, so hollow lines (Fig. 4 and Fig. 5 bottom line) cannot be created. The transform attribute “translate” doesn’t work.

Marker lines

Marker lines can be created by defining a path and reference on it with “textPath”:

                    
<font>
    <font-face font-family='svgMarker' units-per-em="10" />
        <glyph unicode="a" horiz-adv-x="5" d="M-2.5,-5 l5,5 -5,5 z" />
    </font>
<path id="line01" fill="none" stroke="blue" d="M 50 90 C 300 20 20 560 500 90"/>
<text font-family="svgMarker" font-size="16">
    <textPath xlink:href="#line01">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</textPath>
</text>

                

While this method can be sufficient in case of full control on the SVG image, it is not applicable if this is not the case. The amounts of chars (e.g. “a”) has to be estimated to bead the whole line (Fig. 6). Beside this, rendering text is time consuming and therefore hinders performance.

Non-scaling strokes and labels

A common behaviour in GIS software is, to let the outline of an object keep its original width no matter how much the user zooms in. Up to now this behaviour has to be simulated via ECMA Scripting and therefore hinders performance.

The SVG Tiny 1.2 specification defines non-scaling strokes and we hope, that all web browsers will support this in the near future.

Beside this we also have a need a non-scaling behaviour for labels. But with labelling the main problem is, when zooming in, the distance between the map feature and the descriptive text becomes bigger and in the end they lose their “functional link” (Fig. 7). So far the only solution we have is to replace the labels within different scale ranges.

Font marker

GIS software very often uses fonts as markers. While there are tools to convert fonts into SVG fonts, the correct positioning of these converted fonts (markers) remains a problem for SVG. Font markers are positioned centred within the GIS software, SVG text is positioned on the lower left point (Fig. 8). Therefore correct positioning of the point features with markers is not possible as the offset has to be “estimated”.

Simple spatial queries like intersect, completely contain, completely within, identical should be supported (Fig 9-11).

The initial viewport coordinate system of SVG has its origin at the top/left, with the positive x-axis pointing towards the right, the positive y-axis pointing down. However, with maps the positive y-axis is pointing up. For this all spatial data has to be mirrored (Fig. 12).

Mouse events (like click, mouse-over, mouse-move) only operate with the uppermost element in the drawing hierarchy. Event support should be available for all elements at that location, e.g. topmost object, visible objects, or all objects at that location (Fig. 13).

The fast key based zooming and panning tool within the ASV plug-in is not available within the browsers Opera, Firefox and Safari. Zooming and panning has to be done via ECMA scripting and therefore hinders performance.

We don't know how much the open structure of XML encoding raises intellectual property protection and rights management issues when serving spatial information. So it might be an obstacle in using SVG.

Supporting Fonts

Due to the common use of fonts as markers, we hope that SVG fonts will be supported in all web browsers in the near future. Firefox does not support fonts at all, so we implemented a font to image conversion tool to overcome this disadvantage. The lack of quality with this method remains (Fig. 14).