maposmatic-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Maposmatic-dev] Details on why we use Cairo scaling?


From: David Decotigny
Subject: Re: [Maposmatic-dev] Details on why we use Cairo scaling?
Date: Sun, 25 Mar 2012 21:46:19 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi all,

On 03/25/2012 02:01 PM, Thomas Petazzoni wrote:
> Could you refresh our minds on why such a change was needed, and

The idea was:
 - to control the level of details we wanted (most details, except no
   name for tiny little streets)
 - to control the output format (A4...), which was the most wanted
   added value of ocitysmap2 (other than general code
   cleanup/refactoring)

At the time, the level of details with most stylesheets was related to
the zoom level in mapnik, itself controlled by the graphical rendering
area. Let's say we asked mapnik to render Paris in 20x20pt, it would
probably choose zoom level 1. If we asked to render Paris in
20000x20000pt, it would choose a zoom level 16 or more (all these
numbers being pure fictitious guesstimates, ymmv). Or it was the
opposite: based on the rendering area, mapnik would determine the zoom
level and crunch the data based on that. I don't remember.

Since we wanted to control the level of details without having to be
constrained by the exact mapnik graphical rendering area, we decided to
render+rescale. We had to determine a good graphical rendering area that
would be compatible with a predefined zoom level (it's defined in one of
our config files and related to the google pixels), and then render the
associated geographical area in it. For example, when asked to render
Paris, we first compute that the ideal graphical rendering area for a
zoom level 16 is 64328x57423px (random numbers). Then mapnik
automagically uses zoom level 16, and stylesheets follow. After that,
all we had to do was to rescale this into the effective graphical
rendering area we had, based on the "paper size" we wanted. That was the
theory, in a perfect world where people don't mess up with the
transformation matrix...

Now, I don't swear we didn't miss the magic mapnik killer feature that
allowed us to specify the zoom level a priori, and render this in an
graphical area we could specify ourselves. It's possible, but I think at
that time I looked into its source code and probably noticed that the
zoom level was central to determine the size of rendered things, not
really compatible with any specified graphical rendering area. So we
decided to rescale. But, since that time, things might have changed.

Max, can you please confirm?

So first thing you could do is double-check the mapnik code and see 1/
if the level of details is related to the zoom level, 2/ if a
user-specified graphical rendering area for a user-defined geographic
area is compatible with a user-specified zoom level.

Have fun!

- -- 
http://david.decotigny.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9v9JcACgkQld7vhusVrCFH9gCfZr7lefwHKfpxZWOLqP3Zm6ez
W5kAoKpiUwfebDoOotUXIwTL4VbRCmeP
=WN42
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]