[OSM-dev] SVG / Canvas progress report
Nick.Whitelegg at solent.ac.uk
Sun Feb 19 13:48:57 GMT 2006
On further experimentation, SVG is proving somewhat infeasible at the
moment if everything (all nodes, segments and uploaded trackpoints) is
treated as a DOM node. Performance for just nodes and segments is
acceptable but if all uploaded trackpoints in a sensible area (4km x 4km
square) are added, the app a PIII with 256mb memory running Firefox 1.5
/Windows 2000 ground to a halt. Even on a Linux/3ghz/1gb/Firefox 1.5
machine, it was on the slow side.
While the trackpoints could just be added as background graphics, not
having them as nodes would lose one of the principal benefits of SVG (being
able to treat everything as an addressable object) anyhow.
For Canvas on the other hand performance is acceptable on both machines at
present, I am able to drag a dot round the screen with a map as background
at quite an acceptable speed. That said, I obviously need to implement code
to search for the nearest nodes to a mouse click, etc. Canvas of course is
not supported in IE though there is a project to wrap IE's "VML" language
to provide the same API as canvas.
In a more general sense, my own preferences (from a Freemap/countryside
angle) for contributing/editing OSM data (assuming the performance on the
Canvas approach is acceptable) are moving somewhat away from osmeditor and
towards a "command-line upload/web" approach:
1. Develop a standalone command-line application which will read track and
waypoint data from a GPS and upload it to OSM direct;
2. Use the Canvas-based web interface for live data editing; the web
interface will be orientated towards countryside users to tie in with
The rationale for this is:
1. The need to prove that one hasn't infringed copyright by uploading
trackpoints means that at the moment, I have to both upload GPX via the web
interface and upload the track/segment data in osmeditor. The new approach
will handle this better.
2. The new approach will work in both Linux and Windows. I attempted to
produce a Windows version of osmeditor but Qt4 has a significantly
different API compared to Qt3 meaning I was essentially having to maintain
two versions; the Windows version is very behind.
More information about the dev