Engage Mapping and Visualization Technology

This page summarises various conversations that have taken place about the particular technological needs have for mapping and visualization, particularly the ability to create high-quality, interactive vector graphics on the Web.

Various use cases centre around helping visitors to understand the disposition of exhibits around a physical space—either to plan a future or current visit, or else to refresh memory and consolidate impressions after a visit.

More information about mapping requirements, use cases, an directions:

Comparative analysis of museum mapping
James' summary to fluid-work (http://www.nabble.com/On-mapping%3A-where-we-are%2C-where-we're-headed%2C-and-a-starting-use-case-td23751119.html)

Map Authoring

A part of these requirements is what has become known as "Map Authoring". This activity is not yet completely defined, but a draft workflow and scope that has arisen through conversation with Colin and James is as follows:

Institution provides (probably raster-only) rendition of the exhibit space
Imported into authoring application, it is aligned and calibrated to form a "background" to a mini-application
The application allows named regions of the map to be marked up, either as polygonal wide areas, or, more finely, as "point locations" which are associated with a string
- These strings are somehow associated with persistent information held by the institution relating to the disposition of the artefacts - for example, for McCord, these are strings like 1.2.1, 1.2.2 etc. and refer to relatively large regions of their space

The map thus authoured can be then used as part of a variety of application affordances. A straightforward one is as a "search annotation" - whenever any conventional search is performed on the collection, an option can be to highlight the particular subset of exhibits hit by the search by coloured highlighting of the locations they appear in the map. Clearly the reverse query should function too - clicking on a map region should bring up search results list of exhibits appearing there.

A little "jumping off point" is at the MASS MoCA floorplan - this has a quite precise localisation of individual exhibits, in a Javascript-driven popup model. However, it is hard to use this interface to get an overall sense of the disposition of exhibits.

Variability

A crucial point taken away from early discussions on this point is the required "variable fidelity" of map regions - these should be allowed to be as large or small as an institution has patience or desire for refinement, perhaps even mixing "point-style" and "region-style" regions within the same map.

Another point of variability is the fidelity of the original map provided by the institution. After some discussion, it is proposed not to implement any particularly high-fidelity vector editing facilities in early versions of the tool. If the original map as supplied is not suitable for presentation as part of the query interface on the web, it would seem most appropriate to have it re-authoured using conventional technology, such as Adobe Illustrator.

Technology options

An interesting discussion broke out last week (May 2009) relating choice of technologies and persistence for this authoring - as well as for other similar vector interfaces that may be required over the project. Two principal technical directions are the use of Firefox's (and HTML5's) new Canvas API, and the use of SVG, an XML-based vector persistence format from Adobe. A third and undesirable alternative is the use of Microsoft's proprietary VML vector markup language.

On the face of it, many of the affordances are similar - both supply means whereby vector-based images may be rendered, scaled and manipulated within a browser. However, the principal emphasis of SVG is on persistence - as presented in a web document retained mode rendering system, whereby at all times there is a representation of the scene graph as an XML DOM. On the other hand, Canvas is Immediate mode or direct mode - rendering only occurs as a result of imperative calls to the canvas API.

This discussion arose, since naturally the authoring application would have some need for persistence of the resulting diagrams - opening once more the issue of appropriateness of SVG. It would seem unwise to adopt a proprietary format for this case, although on the other hand for the initial space of requirements we would address, even the "Tiny" profile of SVG would seem to have too wide a scope. The discussion is also reopened as to whether SVG might even be an appropriate vehicle for delivering the application itself to the browser - through the use of Javascript and event handlers, an SVG document can acquire a considerable amount of interactivity.

Performance and affordances of SVG and Canvas

The general impression, not really confirmed by very much evidence, is that Canvas is a superior solution for our needs partly because of its performance, and partly because of the greater flexibility it offers for showing "zoomed" or transformed versions of what might otherwise be extremely large documents. Whilst all things being equal, "retained mode" renderers promise to give ultimately greater performance, this depends on a very highly quality of integration and engineering between the layers of the rendering pipeline, perhaps even compiling some into primitives running on the graphics card. Highly interactive SVG applications may well also suffer from performance issues due to the overhead of manipulating the DOM - which is a highly generic data structure not particularly specialised to any task.

SVG viewers must stream down or explicitly reassemble entire documents, whereas taking control of rendering via something like Canvas promises to allow us easier routes more interactive protocols for expressing portions of views.

Circumstantial evidence for this is shown in Google's own choice of technologies for Google Maps - their basic rendering architecture is a version of Canvas, with a Javascript adaptation layer to bridge the same API to Microsoft's VML in IE. This adaptation layer may be, or is at least similar to, ExplorerCanvas. They do not use SVG for rendering.

Information from round the web

Here we will start to collect various summaries, position papers, and useful technologies and projects that relate to this area. Firstly, a transcript of a useful blog posting from Christian Simms which used to appear at botonomy - whilst the blog is no longer available, some of the source has been rescued from Google's cache:

Christian Simms' comparison

Conclusions

I took a graphics class in college a decade and a half ago, and the concepts remain exactly the same.
In general, SVG and canvas are complimentary, rather than competing, technologies. Anything you can do in one,
you can do in the other, but each one is optimized for certain situations.

Below, I put together a table summarizing the tradeoffs.

Feature	SVG	Canvas
Draw geometric shapes	Easy: use SVG tags	Easy: use API
Manipulate pictures	Hard: Need to use poorly- or un-implemented image/feImage tags	Easy: use API
Object Model	Easy: You declare model, browser renders it. Model is part of DOM.	Hard: No model. You can maintain your own Javascript model (fun!).
User interaction	Easy: Event model is integrated	Hard: None out of the box - you have to implement all event handling infrastructure, like tracking coordinates of objects in model.
Resizing	Easy: that's the S in Scalable	Medium: You write the resizing code

You should know which technology to use based on your project and requirements.
If you're just rendering some graphics, and you have no need for user interactivity, then the canvas tag is more appropriate.
If you want to have user interactivity, or if you have some other need for a model or user interaction, then SVG is more appropriate.

Ignoring the above trade-offs, if you want a technology that runs in all major browsers right now, then you have to go with SVG.
And that's probably good, because my completely unscientific guess is that SVG is more appropriate for most (but not all!) applications.

Bottom line: SVG tastes great, but canvas is less filling.
[This was written in February 2006]

Performance comparison at Intertwingly a small app is written as far as possible identically in SVG and Canvas, with some timings. A long blog thread with relatively unconclusive results, and some flaws exposed in the methodology. A general sensation that Canvas is expected to be faster, with mild evidence in favour.

SVG and HTML referenced by Simms on the issue of "how hard it is to embed an SVG document portably in HTML". IE typically requires an <embed> tag, it is not clear that external scripting will be possible.

Raphael, a Javascript library which portably renders charts and documents on both SVG and VML. This does not deal with the case of dynamic documents - no facilities for event handling, etc.

Processing and Processing.js

Processing.js, a project initiated by John Resig, bridges the highly popular Processing graphics framework to Javascript on Canvas. Processing itself includes rich support for SVG both import and export, but this is locked up within Java-specific libraries. Evidence of bridging work between Processing.js itself and SVG can be seen in this announcement of font support which can interpret SVG fonts converted from TTF by Batik.

Processing is attractive since it promises a model whereby artefacts written to render on the client-side as part of a web interface may also be rendered desktop or serverside, as well as being suitable to be prepared for publication-quality graphics with higher-quality renderers. Processing is also popular amongst artistic and design communities, allowing easier access to design resources, samples and libraries.