Discussion:
[OSM-dev] "Retina" tiles - best way to support them?
Frederik Ramm
2012-06-26 21:05:47 UTC
Permalink
Hi,

I have had some people asking whether I could supply them with
"Retina" map tiles. "Retina" is an Apple brand name for higher
resolution displays, and these users tend to mean tiles with twice the
resolution.

I wonder if anyone has done this already. I can think of a number of
possible angles to attack this:

1. Double all font sizes, line widths, etc. in the Mapnik style file
(recent Mapnik versions also have a built-in scaling option that
achieves about the same) and adapt all scale denominators accordingly.

This would mean that meta tile size, tile size, and everything else
would remain unchanged but you'd be shifting everything by one zoom
level - what was on one z16 tile before is now on four z17 tiles. The
"Retina" user would see less detail on the same zoom level and therefore
would have to go down to z19 to see what is currently shown on 18.

Also, font nastiness along the metatile edges would increase; the amount
of font nastiness depends on the ratio of tile size to font size, so
doubling font sizes and keeping metatile sizes will increase label
clipping and other strange things. (Simply increasing the buffer doesn't
help.)

2. Modify style as per 1., but also double the size of meta tiles to
4096x4096. Cut 16x16 normal tiles out of one meta tile, rather than 8x8.
This avoids the increase in font nastiness but requires internal
processes to adapt to larger metatiles. The "zoom level shift" problem
is the same as in 1.

3. Modify style as per 1., double size of meta tiles to 4096x4096, and
double size of tiles to 512x512. This avoids the increase in font
nastiness *and* it has the nice effect that one "Retina" tile at a
certain zoom level shows exactly the same content as a normal tile, just
on 512x512 instead of 256x256 and therefore at twice the resolution. It
would, however, require clients (OpenLayers et al.) to work with the
larger tile size.

Your thoughts on these options - are there more than these three,
perhaps? - would be most welcome.

("Tiles for printing" is a very similar issue - "print" users tend to
want quad-resolution tiles, and again you have the options of shifting
the zoom level by 2 or making 1024x1024 tiles.)

Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49?00'09" E008?23'33"
Frederik Ramm
2012-06-26 22:27:42 UTC
Permalink
Hi,
Post by Frederik Ramm
3. Modify style as per 1., double size of meta tiles to 4096x4096, and
double size of tiles to 512x512. This avoids the increase in font
nastiness *and* it has the nice effect that one "Retina" tile at a
certain zoom level shows exactly the same content as a normal tile, just
on 512x512 instead of 256x256 and therefore at twice the resolution. It
would, however, require clients (OpenLayers et al.) to work with the
larger tile size.
I just tried this out and found that, on a standard non-mobile Firefox
browser, OpenLayers displays the new 512x512 tile just fine, it scales
it to 256x256 in the browser. I can then use the browser's "zoom"
function to blow up the OpenLayers display and while everything becomes
jaggy when I do this with normal tiles, the map still looks nice when
using the double resolution tiles. Does this mean that it would be an
acceptable viewing experience for mobile users as well?

mod_tile does not require modifications to work with 512x512 tiles;
Tirex requires a couple. Also, I'm running this on the standard OSM
style and Mapnik 2.0 using the AGG renderer's "scale factor" parameter
and it doesn't scale shields or bitmap icons; I'll see if that's any
better with 2.1 - else I'll have to do the old style "take xml and
double all the sizes" route.

Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49?00'09" E008?23'33"
Frederik Ramm
2012-07-05 07:44:25 UTC
Permalink
Hi,
Post by Frederik Ramm
3. Modify style as per 1., double size of meta tiles to 4096x4096, and
double size of tiles to 512x512. This avoids the increase in font
nastiness *and* it has the nice effect that one "Retina" tile at a
certain zoom level shows exactly the same content as a normal tile, just
on 512x512 instead of 256x256 and therefore at twice the resolution. It
would, however, require clients (OpenLayers et al.) to work with the
larger tile size.
This option sounded best to me as well.
Post by Frederik Ramm
I just tried this out and found that, on a standard non-mobile
Firefox browser, OpenLayers displays the new 512x512 tile just fine,
it scales it to 256x256 in the browser. I can then use the browser's
"zoom" function to blow up the OpenLayers display and while
everything becomes jaggy when I do this with normal tiles, the map
still looks nice when using the double resolution tiles. Does this
mean that it would be an acceptable viewing experience for mobile
users as well?
Most likely, I?d guess.
I?d like to try it on some devices with pixel ratio > 1, like the Nexus
One with its penTile display
http://en.wikipedia.org/wiki/Nexus_One#Hardware
or the iPhone 4.
Is your test setup publicly accessible?
It is now, here:

http://mull.geofabrik.de/hires.html

By default this will come up with standard Mapnik tiles from osm.org,
but you can switch to my hires tiles in the layer switcher. If I do this
in Firefox on my desktop machine, there's hardly any difference between
the two, as OL downscales the images from 512x512 to 256x256 for
display. Only if you right-click on an image will you see that it is
indeed bigger than normal.

I'd be interested in hearing from users of high-resolution displays if
these big tiles actually make a difference (except being slower to
load...).

Feel free to play with these tiles (tile URL is e.g.
Loading Image...), but note that this is a
play server that may or may not be working, and is likely to be slow
(currently pre-rendered only up to z11), and also I'll probably drop
this tile set in a few weeks so if you read this in a mailing list
archive later the link will be dead.

Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49?00'09" E008?23'33"
Martin Koppenhoefer
2012-07-05 08:32:28 UTC
Permalink
I'd be interested in hearing from users of high-resolution displays if these
big tiles actually make a difference (except being slower to load...).
actually it doesn't make any difference on an iPhone4 (960x640px), I
guess at least with this particular OL settings they are displayed at
50% like on your desktop.

Btw.: the tiles are NOT identical also apart from the resolution, look
e.g. at F?rth: on the normal tiles there is Erlangen above it, while
on the hires tiles it isn't.

On the other hand it wouldn't even be desirable (IMHO) to have the
exact same tile at a higher resolution. To make best benefit from more
pixels on the display it would be ideal to have a dedicated style to
be able to get more details on the "same" zoom level. Something in
between the detail level of the normal style (currently too small) and
the next zoom level would be nice (so you wouldn't only get a crisper
view but also slightly more detail).

Another thing is that on mobile devices traffic and loading speed are
often an issue, and upscaled images (standard tiles at 200%) are
generally "sufficient" for most users I guess, with the benefit of
fewer data to be transfered (and cached!). Especially when it comes to
offline tiles of bigger areas the increase in memory consumption of
those hires tiles is significant (around 3 times on a rough estimate
with your tiles).

To overcome these issues rendering on the device could be a solution
(not sure what this means in terms of increased battery consumption),
or maybe a hybrid approach (hillshading and contours / area fills
prerendered, overlayed with vector roads and pois). This would even
lead to a native stepless zooming experience (like a WMS), and the
vectors could maybe be used for other things as well (routing (?),
feature search and highlighting).

cheers,
Martin
Frederik Ramm
2012-07-05 09:11:05 UTC
Permalink
Hi,
Post by Martin Koppenhoefer
Btw.: the tiles are NOT identical also apart from the resolution, look
e.g. at F?rth: on the normal tiles there is Erlangen above it, while
on the hires tiles it isn't.
Yes, but that's just normal style idiosyncracies - whatever comes first
is rendered first, it's more or less random.
Post by Martin Koppenhoefer
On the other hand it wouldn't even be desirable (IMHO) to have the
exact same tile at a higher resolution. To make best benefit from more
pixels on the display it would be ideal to have a dedicated style to
be able to get more details on the "same" zoom level.
Probably depends on just *how* much bigger your resolution is.
Post by Martin Koppenhoefer
Another thing is that on mobile devices traffic and loading speed are
often an issue, and upscaled images (standard tiles at 200%) are
generally "sufficient" for most users I guess
Sure. When CloudMade launched their tile service a while ago, they even
offered a special "mobile" style designed to produce tiles that use less
space, and I believe they even cut tiles to 64x64 or so in order to
reduce unnecessary downloads. It is clear that double-resolution tiles
like the ones I made here are a luxury that only those with lots of
bandwidth and storage space will want to afford.
Post by Martin Koppenhoefer
To overcome these issues rendering on the device could be a solution
Yes, I think rendering on the device is certainly the future, and bitmap
tiles will probably be phased out in a couple of years, except maybe for
overview maps on very low zoom levels.
Post by Martin Koppenhoefer
This would even
lead to a native stepless zooming experience (like a WMS), and the
vectors could maybe be used for other things as well (routing (?),
feature search and highlighting).
All of that is already available in commercial applications like
Skobbler's ForeverMap today and there are already promising Open Source
in-browser rendering engines so it's pretty clear that this is where the
journey goes. I'm not making high-resolution tiles as a replacement for
vector rendering - just as an interim solution until vector rendering
for the masses is actually here.

Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49?00'09" E008?23'33"
Peter Wendorff
2012-07-05 09:11:38 UTC
Permalink
Post by Frederik Ramm
Hi,
Post by Frederik Ramm
3. Modify style as per 1., double size of meta tiles to 4096x4096, and
double size of tiles to 512x512. This avoids the increase in font
nastiness *and* it has the nice effect that one "Retina" tile at a
certain zoom level shows exactly the same content as a normal tile, just
on 512x512 instead of 256x256 and therefore at twice the resolution. It
would, however, require clients (OpenLayers et al.) to work with the
larger tile size.
This option sounded best to me as well.
Post by Frederik Ramm
I just tried this out and found that, on a standard non-mobile
Firefox browser, OpenLayers displays the new 512x512 tile just fine,
it scales it to 256x256 in the browser. I can then use the browser's
"zoom" function to blow up the OpenLayers display and while
everything becomes jaggy when I do this with normal tiles, the map
still looks nice when using the double resolution tiles. Does this
mean that it would be an acceptable viewing experience for mobile
users as well?
Most likely, I?d guess.
I?d like to try it on some devices with pixel ratio > 1, like the Nexus
One with its penTile display
http://en.wikipedia.org/wiki/Nexus_One#Hardware
or the iPhone 4.
Is your test setup publicly accessible?
http://mull.geofabrik.de/hires.html
By default this will come up with standard Mapnik tiles from osm.org,
but you can switch to my hires tiles in the layer switcher. If I do
this in Firefox on my desktop machine, there's hardly any difference
between the two, as OL downscales the images from 512x512 to 256x256
for display. Only if you right-click on an image will you see that it
is indeed bigger than normal.
You may simply zoom in in Firefox using Strg+"+" to see the benefit ;)

regards
Peter
Igor Brejc
2012-07-05 15:05:25 UTC
Permalink
If I do this in Firefox on my desktop machine, there's hardly any
difference between the two, as OL downscales the images from 512x512 to
256x256 for display. Only if you right-click on an image will you see that
it is indeed bigger than normal.
Actually, the text rendering does look better even on the desktop,
especially on very small texts. But I guess you could achieve the same
effect by downsampling the tile on the server side, without the need for
transmitting 512x512 tiles.

Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120705/4d800198/attachment.html>
Andreas Labres
2012-07-06 08:00:03 UTC
Permalink
Post by Frederik Ramm
http://mull.geofabrik.de/hires.html
Looks gorgeous!

Side by side comparison: Loading Image...

Now the icons should also be "retinated"... ;)

BTW, it is impossible to touch the current OpenLayers elements on an iPhone 4S.
Isn't there a "mobile" OL style available?

I'm looking forward to printing an A0 size poster of this... :)

/al
Dane Springmeyer
2012-07-06 19:24:25 UTC
Permalink
Post by Andreas Labres
Post by Frederik Ramm
http://mull.geofabrik.de/hires.html
Looks gorgeous!
Side by side comparison: http://www.openstreetmap.at/userfiles/vergleich.png
Now the icons should also be "retinated"... ;)
The stylesheet should move to use svg icons, which Mapnik >= 2.x supports.

Dane
Robert Joop
2012-07-17 18:25:06 UTC
Permalink
[Since I kicked off this branch of the thread, I take the liberty of
following up even though two weeks have passed, due to vacation.]
Post by Frederik Ramm
Post by Frederik Ramm
3. Modify style as per 1., double size of meta tiles to 4096x4096, and
double size of tiles to 512x512. This avoids the increase in font
nastiness *and* it has the nice effect that one "Retina" tile at a
certain zoom level shows exactly the same content as a normal tile, just
on 512x512 instead of 256x256 and therefore at twice the resolution. It
would, however, require clients (OpenLayers et al.) to work with the
larger tile size.
This option sounded best to me as well.
Post by Frederik Ramm
I just tried this out and found that, on a standard non-mobile
Firefox browser, OpenLayers displays the new 512x512 tile just fine,
it scales it to 256x256 in the browser. I can then use the browser's
"zoom" function to blow up the OpenLayers display and while
everything becomes jaggy when I do this with normal tiles, the map
still looks nice when using the double resolution tiles. Does this
mean that it would be an acceptable viewing experience for mobile
users as well?
Most likely, I?d guess.
I?d like to try it on some devices with pixel ratio > 1, like the Nexus
One with its penTile display
http://en.wikipedia.org/wiki/Nexus_One#Hardware
or the iPhone 4.
Is your test setup publicly accessible?
http://mull.geofabrik.de/hires.html
By default this will come up with standard Mapnik tiles from
osm.org, but you can switch to my hires tiles in the layer switcher.
If I do this in Firefox on my desktop machine, there's hardly any
difference between the two, as OL downscales the images from 512x512
to 256x256 for display. Only if you right-click on an image will you
see that it is indeed bigger than normal.
I'd be interested in hearing from users of high-resolution displays
if these big tiles actually make a difference (except being slower
to load...).
With your page on e.g. an iPhone, the two sets of tiles look identical,
but that?s because its a huge page squeezed onto the tiny display, so
even the standard tiles have far too high resolution.
And one cannot zoom into the page as the gesture is caught by openlayers
for zooming into the map.

But I?ve copied your page, adjusted the style and tiles URIs and added a
viewport.
As expected, it doesn?t make any visible difference on an iPhone 3
(pixel ratio 1), but the difference is remarkable on e.g. an HTC Sensation
(pixel ratio 1.5) or an iPhone 4 (pixel ratio 2).

See https://mlist.timesink.de/osm-geofabrik-highres/ for some screen
shots.

rj
Peter Körner
2012-07-20 08:07:37 UTC
Permalink
Post by Robert Joop
But I?ve copied your page, adjusted the style and tiles URIs and added a
viewport.
As expected, it doesn?t make any visible difference on an iPhone 3
(pixel ratio 1), but the difference is remarkable on e.g. an HTC Sensation
(pixel ratio 1.5) or an iPhone 4 (pixel ratio 2).
See https://mlist.timesink.de/osm-geofabrik-highres/ for some screen
shots.
That looks amazing!
Can the index.html be reached somehow to see the result on my own devices?

Peter
Robert Joop
2012-07-20 08:57:26 UTC
Permalink
Post by Peter Körner
Post by Robert Joop
But I?ve copied your page, adjusted the style and tiles URIs and added a
viewport.
As expected, it doesn?t make any visible difference on an iPhone 3
(pixel ratio 1), but the difference is remarkable on e.g. an HTC Sensation
(pixel ratio 1.5) or an iPhone 4 (pixel ratio 2).
See https://mlist.timesink.de/osm-geofabrik-highres/ for some screen
shots.
That looks amazing!
Can the index.html be reached somehow to see the result on my own devices?
You should adjust the viewport to one that fits your device.
I attach the file, it should work even when you put it on your local
machine accessible via http://localhost/mobile.html .

Have fun,
rj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120720/51bd7095/attachment.html>
Paul Norman
2012-06-27 00:52:47 UTC
Permalink
From: Frederik Ramm [mailto:frederik at remote.org]
Subject: [OSM-dev] "Retina" tiles - best way to support them?
Hi,
I have had some people asking whether I could supply them with
"Retina" map tiles. "Retina" is an Apple brand name for higher
resolution displays, and these users tend to mean tiles with twice the
resolution.
I wonder if anyone has done this already. I can think of a number of
1. Double all font sizes, line widths, etc. in the Mapnik style file
(recent Mapnik versions also have a built-in scaling option that
achieves about the same) and adapt all scale denominators accordingly.
I did some work on this for print where I wanted to print 1200 DPI maps. I
found that with one exception, everything just worked if I created a
mapnik.Image of the higher resolution and used an appropriate scale factor.
https://github.com/pnorman/mapbook/blob/master/mapbook.py#L201 is the
relevant section of the code. Unfortunately I haven't had time to work on it
lately.

The one exception to it just working is png POI graphics. These appear at a
reduced scale with mapnik's AGG renderer and at the same scale but blocky
with the mapnik cairo-based PDF renderer. This is an inherent limitation of
bitmapped graphics - it either looks tiny or it looks bad. Fonts and line
widths worked perfectly.

What I would suggest is a version of osm.xml which uses SVG icons instead of
PNG icons, allowing for use at any resolution.

Some other points you'll find at high resolution
- mapnik takes significantly more CPU time to render at high resolutions
- The same style that works at ~100 DPI on a normal screen doesn't work at
1200 DPI printed, aside from any technical considerations.
- The difference in appearance you get with each doubling of the resolution
decreases as you increase resolution so you may not want to go to the max
resolution of the device you have if it is > 300 DPI
- DPI images are large and it takes planning to deal with them

Of the three options you listed, I find 3 the best - it keeps a given z/x/y
tile representing the same area.
Frederik Ramm
2012-06-27 06:40:31 UTC
Permalink
Hi,
Post by Paul Norman
I did some work on this for print where I wanted to print 1200 DPI maps. I
found that with one exception, everything just worked if I created a
mapnik.Image of the higher resolution and used an appropriate scale factor.
https://github.com/pnorman/mapbook/blob/master/mapbook.py#L201 is the
relevant section of the code. Unfortunately I haven't had time to work on it
lately.
For my normal printing needs, I always produce SVGs with nik2img and
then have them rasterized at higher resolution. Of course the cost is
blocky PNG icons. TBH I'd prefer Mapnik to produce large but blocky PNGs
when using a scale factor > 1 - this becomes doubly important in the
case of the ShieldSymbolizer where you'd want your font to fit in the
shield provided, which isn't the case with PNG shield icons and scaling
at the moment.
Post by Paul Norman
What I would suggest is a version of osm.xml which uses SVG icons instead of
PNG icons, allowing for use at any resolution.
That would of course be ideal. Some, but not all, icons used in the
standard OSM style are PNGs made from SVG already.

Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49?00'09" E008?23'33"
pavithran
2012-06-27 13:08:54 UTC
Permalink
Post by Paul Norman
The one exception to it just working is png POI graphics. These appear at a
reduced scale with mapnik's AGG renderer and at the same scale but blocky
with the mapnik cairo-based PDF renderer. This is an inherent limitation of
bitmapped graphics - it either looks tiny or it looks bad. Fonts and line
widths worked perfectly.
What I would suggest is a version of osm.xml which uses SVG icons instead of
PNG icons, allowing for use at any resolution.
Even I tried playing out with both mapnik and osmarender . In
osmarender it uses the default SVG but the style was not that easily
scalable.

Mapnik default would do better with SVG . Anyways Mapquest already
uses SVG in its style as per
https://github.com/MapQuest/MapQuest-Mapnik-Style/tree/6f7ea2723c07a1db2d17c2336dd3a0b3dd2d6fe9/mapquest_symbols

Regards,
Pavithran
--
pavithran sakamuri
http://look-pavi.blogspot.com
Sven Geggus
2012-06-27 08:18:40 UTC
Permalink
Post by Frederik Ramm
Your thoughts on these options - are there more than these three,
perhaps? - would be most welcome.
Hm, I consider this to be a renderer rather than a stylefile issue.

On Mapserver (which is unpopular in the OSM world for some reason)
there is are two options for this: RESOLUTION and DEFRESOLUTION.

Imagine you have a Style designed for desktop screens like most styles and
you want to go for a 200 DPI Output resolution you can simply put the
following into a mapfile:

RESOLUTION 200
DEFRESOLUTION 96 (defaults to 72)

http://mapserver.org/mapfile/symbology/construction.html#symbol-units

I think something like this should also be implemented in Mapnik, at least
in the long run.

Regards

Sven
--
"A strategy for rewarding artists that regulates 'copies' makes as much sense
in the digital age as a strategy for controlling greenhouse gases that
regulates breathing." (Lawrence Lessig)
/me is giggls at ircnet, http://sven.gegg.us/ on the Web
Stefan de Konink
2012-06-27 17:16:44 UTC
Permalink
Post by Frederik Ramm
I have had some people asking whether I could supply them with
"Retina" map tiles. "Retina" is an Apple brand name for higher
resolution displays, and these users tend to mean tiles with twice
the resolution.
I am glad that "Retina" raises the issue, that is already present on
Android, high resolution displays make the map unreadible. One of the
angles I didn't saw you comment on was: going svg.gz all the way.
Rendering tiles in SVG, doing so with a clue, for example fixed poit
coordinates allows a decent compression over an easy zoom.

The higher the DPI the more bandwidth is required to serve the tiles
anyway, there must be some threshold where it is really more worthwile
to render in whatever GL standard on the client, than sending over
bitmaps as (effectively as textures).


Stefan
Robert Joop
2012-06-27 21:12:24 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Frederik Ramm
I have had some people asking whether I could supply them with
"Retina" map tiles. "Retina" is an Apple brand name for higher
resolution displays, and these users tend to mean tiles with twice
the resolution.
I am glad that "Retina" raises the issue, that is already present on
Android, high resolution displays make the map unreadible. One of the
Why unreadable?
What viewport setting do you use?
For example, when you use the same viewport width 320 on both iPhone
and iPhone 4, then the map looks the same on both devices, right?
It?s just that it doesn?t look as crisp as could be on the iPhone 4.
angles I didn't saw you comment on was: going svg.gz all the way.
Rendering tiles in SVG, doing so with a clue, for example fixed poit
coordinates allows a decent compression over an easy zoom.
How good is the SVG support on mobile devices?
What about devices without decent SVG support?
Do you want to have two rendering pipelines, one SVG for higher pixel
ratios and one PNG for less capable devices/browsers?

rj
Stefan de Konink
2012-06-28 17:09:42 UTC
Permalink
Why unreadable? What viewport setting do you use?
A mapquest widget is used within a native app.
Post by Stefan de Konink
angles I didn't saw you comment on was: going svg.gz all the
way. Rendering tiles in SVG, doing so with a clue, for example
fixed poit coordinates allows a decent compression over an easy
zoom.
How good is the SVG support on mobile devices?
<http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Mobile_profiles>
What about devices without decent SVG support?
Serve legacy PNG available at fixed resolutions.
Do you want to have two rendering pipelines, one SVG for higher
pixel ratios and one PNG for less capable devices/browsers?
Yes, don't break what ain't broken, and introduce a new better way
that is slowly adopted.


Stefan
Robert Joop
2012-07-01 21:16:04 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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
Igor Brejc
2012-07-02 12:12:43 UTC
Permalink
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 <
Post by Robert Joop
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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.
- 31 seconds with Firefox 3.6
- 6 seconds with Firefox 10
- 2 seconds with Chrome 20
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 at openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120702/89ad2875/attachment.html>
Igor Brejc
2012-06-28 08:22:51 UTC
Permalink
Hi,

FWIW, Maperitive provides a "resolution" parameter to its generate-tiles
command. The parameter is an integer value indicating the scale to use when
rendering tiles - the default 1 renders 256x256 tiles. If you set it to 2,
you get 512x512.
Technically the whole thing is implemented by scaling the graphics, which
is quite easy to do in GDI+ (.NET graphics engine). The user doesn't have
to change the map style.
I used the same technique to achieve the subpixel accuracy in Maperitive
(since GDI+ doesn't provide for this):
http://braincrunch.tumblr.com/post/13459650973/maperitive-beta-subpixel-accuracy

Best regards,
Igor
Hi,
I have had some people asking whether I could supply them with "Retina"
map tiles. "Retina" is an Apple brand name for higher resolution displays,
and these users tend to mean tiles with twice the resolution.
I wonder if anyone has done this already. I can think of a number of
1. Double all font sizes, line widths, etc. in the Mapnik style file
(recent Mapnik versions also have a built-in scaling option that achieves
about the same) and adapt all scale denominators accordingly.
This would mean that meta tile size, tile size, and everything else would
remain unchanged but you'd be shifting everything by one zoom level - what
was on one z16 tile before is now on four z17 tiles. The "Retina" user
would see less detail on the same zoom level and therefore would have to go
down to z19 to see what is currently shown on 18.
Also, font nastiness along the metatile edges would increase; the amount
of font nastiness depends on the ratio of tile size to font size, so
doubling font sizes and keeping metatile sizes will increase label clipping
and other strange things. (Simply increasing the buffer doesn't help.)
2. Modify style as per 1., but also double the size of meta tiles to
4096x4096. Cut 16x16 normal tiles out of one meta tile, rather than 8x8.
This avoids the increase in font nastiness but requires internal processes
to adapt to larger metatiles. The "zoom level shift" problem is the same as
in 1.
3. Modify style as per 1., double size of meta tiles to 4096x4096, and
double size of tiles to 512x512. This avoids the increase in font nastiness
*and* it has the nice effect that one "Retina" tile at a certain zoom level
shows exactly the same content as a normal tile, just on 512x512 instead of
256x256 and therefore at twice the resolution. It would, however, require
clients (OpenLayers et al.) to work with the larger tile size.
Your thoughts on these options - are there more than these three, perhaps?
- would be most welcome.
("Tiles for printing" is a very similar issue - "print" users tend to want
quad-resolution tiles, and again you have the options of shifting the zoom
level by 2 or making 1024x1024 tiles.)
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49?00'09" E008?23'33"
______________________________**_________________
dev mailing list
dev at openstreetmap.org
http://lists.openstreetmap.**org/listinfo/dev<http://lists.openstreetmap.org/listinfo/dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120628/a2a7beb2/attachment-0001.html>
Continue reading on narkive:
Loading...