SVG has several problems: 1. It's a general-purpose graphics format. It allows a lot of things, but that comes with a cost - implementing and maintaining a SVG rendering engine is difficult, making it efficient is even more so. 2. Although SVG is supposed to be a standard, not everyone implements its renderers (or converters) the same way. Adobe's implementation is particularly buggy & non-compliant (see http://igorbrejc.net/openstreetmap/maperitive-vs-adobe-illustrator). Oh yes, and _very_ slow, especially if you want to have high-precision text positioning on a per-letter basis (see http://maperitive.net/docs/manual/Commands/ExportSvg.html#Precision%20Typography) - this is why Maperitive SVG sample you tried is so slow. 3. You're stuck with existing implementations of rendering engines. Writing your own would be a mammoth (and wasteful) effort, because of the point #1.
SVG comes in handy when you want to have a map that can be imported as a vector drawing into desktop publishing software (Illustrator, Inkscape etc). For rendering maps on the fly on mobile devices, I'd recommend using a native renderer or HTML5. Igor On Sun, Jul 1, 2012 at 11:16 PM, Robert Joop < 5313501608656...@rainbow.in-berlin.de> wrote: > On 12-06-28 19:09:42 CEST, Stefan de Konink wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 27-06-12 23:12, Robert Joop wrote: > > > Why unreadable? What viewport setting do you use? > > > > A mapquest widget is used within a native app. > > Ok, I had web browsers in mind, out of personal experience. > > > > How good is the SVG support on mobile devices? > > > > <http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Mobile_profiles> > > Well, this doesn’t tell me anything about the quantity and quality of > the support on the devices out in the field. > But this doesn’t concern you, I suppose, as with an app you’ll cover > only a small part of the market (expressed in percentage of devices, > not in percentage of market share, of course), and you can know those > devices fairly well, or bring along the libraries as needed...? > > Me, thinking along mobile web browser support, am much more reluctant > when it comes to using SVG heavily on them. > > Actually, thinking about it, I wonder whether desktop browsers are up for > it. Following the hint on http://wiki.openstreetmap.org/wiki/SVG > I tried the OSM SVG export, central Cologne at zoom level 15, and loaded > the result in Firefox 3.6 on my netbook: it takes ages to render, some > 45 seconds. > The Maperitive example offered there for the center of Dublin takes some > 30 seconds to render. > > The remainder of the tests is with the OSM Cologne export. > My desktop PC is even slower, 100 seconds with Firefox 3.6. > A more current desktop PC at work: > - 31 seconds with Firefox 3.6 > - 6 seconds with Firefox 10 > - 2 seconds with Chrome 20 > > But how about mobile devices? In case anybody's as curious as myself: > > Acer A100 (Android 4): some 14 s > Opera Mobile on it seems slightly faster > Samsung Galaxy Tab 10.1: also some 14 s; panning and zooming almost fast > enough to use. > Windows Phone 7: no SVG support > HTC Desire, HTC Sensation: I get a blank page! > Apple iPhone: more than 2 minutes till it has finished rendering, and > then panning and zooming feels glacial as well. > Apple iPhone 4: some 33 s where nothing seems to happen, then the finished > result appears. Panning and zooming is too slow to use. > > (On most devices, one can watch the map getting rendered.) > > To sum it up, I believe it is safe to say that heavy use of SVG like those > from OSM exports should only be used on targets you know very well. ;-) > > YMMV, > have fun, > rj > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev